I noticed that one of our disk-based Volumes used a label name similar to that of our tape-based Volumes. To avoid confusion, I will rename that Volume. But, renaming a Volume is not simple, nor recommended if the Volume contains data. It is better to migrate the data instead.
The Volume in question has MediaId = 42 (seriously!):
| 42 | PEQ574L4 | Append | 1 | 4,144,705,431 | 0 | 31,536,000 | 1 | 0 | 1 | File | 2009-09-01 08:03:23 |
That format is similar to our tape labels. Hmmm, I wonder what jobs are on that Volume. Fortunately, I already know how to do this.
mysql> SELECT JobId, Job, Name FROM Job WHERE JobId IN (select distinct JobId from JobMedia where MediaId in (42)); +-------+--------------------------------------+---------------+ | JobId | Job | Name | +-------+--------------------------------------+---------------+ | 90 | BackupCatalog.2009-08-27_23.10.00_14 | BackupCatalog | | 96 | BackupCatalog.2009-08-28_23.10.00_21 | BackupCatalog | | 99 | BackupCatalog.2009-08-29_23.10.00_24 | BackupCatalog | | 100 | BackupClient1.2009-08-30_23.05.00_25 | BackupClient1 | | 102 | BackupCatalog.2009-08-30_23.10.00_27 | BackupCatalog | | 111 | BackupCatalog.2009-08-31_23.10.00_39 | BackupCatalog | +-------+--------------------------------------+---------------+ 6 rows in set (0.03 sec) mysql>
Ahh good, just simple jobs, nothing of ‘real’ data. This is good.
I didn’t document any of this process. But I did use Migration to move the backup data from the Default Pool to the new File Pool. I had to bump Max Concurrent jobs for the SD and the FD. This worked well. I also had to temporarily create a new Device so the SD could both read and write at the same time (but from different Devices). One Device mounted the old Pool, the other the new Pool.
The whole setup took about an hour to get right, and then another 30 minutes to copy over the 9GB or so of data.
Sorry I don’t have more detail.
