Showing results for 
Search instead for 
Did you mean: 

migration LTO6 to LTO8 tape

Level 2


We have a new backup environment: Netbackup 10.00, LTO8 and LTO6 library, Linux OS. Everything is up and running.

Now, we want to eliminate the LTO6 tape, it´s meaning, we are migrating LTO6 tape to LT08, following the tape import process, step below:

Phase 1: is relatively quick as NetBackup only reads the tape headers off the media.

Phase 2, NetBackup recreates the file information in the image database. This phase may take some time to complete, depending on the number and size of the imported images. Usually, the phase gets 24 hours to successfully completed, I don´t know if it needs to scan the entire tapes and recreate the catalog entry.

Phase 3 : Duplication

So, I would like to know if there is other way to run the migration step, the import process is quite long.

Could I export the catalog from the old server and import it into the new one?  Could I add the legacy master into the production master as second media or have two masters?

The  LTO-8 libray is not able to read and write LTO6 tape, because the inclusion of TMR technology and barium ferrite limits backward compatibility to one generation. As a result, LTO-8 can read and write to LTO-07.

Any ideas?

Thanks , have good day


Level 6

Hi @fabiomoraes05 

That sucks about the backwards compatibility of LTO8 (before then of course it could read 2 generations back). Anyway I digress. 

If the new NetBackup master has the same name (and platform type) as the old master, then you could do a catalog recovery to the new system (there is an article for this Once done use the device wizard to add the LTO8 library and start duplicating tapes (no import required). 

There is no other simple way to extract the catalog information from the old system to import into the new system without engaging Veritas consulting or another third party (such as Stone Ram - @StoneRam-Simon ). 


Level 6
Partner    VIP    Accredited Certified

There is also a limitations on doing a media import...  If you have duplicate copies of images, you can only import ONE of them.  Also you could import images that have since expired (this may be what you want, but it could also result in you duplicating data that you no longer need, and this slowing down the whole process..)

If your aim is to have the original catalog on the destination, then this will either require a "merge" of the catalogs now you have the NEW environment configured (something that our Tranzman Solution is specifically designed for, although its not a free option (sorry)) 
There used to be a document for DR relating to the "recovery without import" which could be done using "cat_export" and "cat_import", along with transfer of the IMAGES folder to migrate image data, please note that these tools DO NOT fully work all image properties, (VMWARE, and Replication Director, and probably others too..)
If you were to look at using the cat_export / cat_import you would also create an "inconsistency" between the image database and media database as these tools do not do anything for the media database.  You would need to create NEW media records for all the media, and put them into a pool that would not be used by any NEW backups.  However the MEDIA records would not have correct timeassigned or image counts for the imported media, this may/may not be an issue if the aim is to duplicate and then expire them off).

Please also note that the "import" method you are using as media would be treated as "new" when its added/discovered in the library,  I would recommend that you make sure these media are placed into a pool that is not used by any new backups too.

As for the DUPLICATION from LTO6 to LTO8, there is no way around the need to have both drives available.
You may be able to script some of the duplication to priorities those with the longest retention first..  (although that will work best if you can get the catalog merged first. as the MEDIA IMPORT will rebase the expiration date based on the retention and the date of the IMPORT.