I read this as; replicate a disk pool old to new, then detach this new disk pool from one master server and re-attach new pool to a different master server, then perform a catalog recovery.
Questions:
1) Current version of NetBackup?
2) Old master server OS version?
3) New master server OS version?
4) Size of contents of old disk pool?
5) Size of NetBackup catalog?
6) Is either old or new master clustered?
7) Is either an appliance?
My thoughts:
(and the actual running order, and appropriateness of any of these steps is entirely dependent upon the sizes revealed by the above questions)
- identify exactly where (exact drive letter, folder path spelling, spacing, and upper/lower case-ness of current NetBackup installation path - you will need this later)
- if new mast is Unix/Linux - check the ulimit and semaphore requirements beforehand - and set them in new server beforehand.
- identify a suitable tool whcih can "synchronize" entire folder trees.
- test that tool, understand it's methods (archive bit based (not good), modified date based (good)).
- can the synchronize be throttled?
- attach new storage to old master
- first full synchronize (on low-ish throttle so as to not steal I/O from old disk pool in what is still production NetBackup environment) from old pool to new pool - which may run for several days - and track your throughput.
- wait a day
- run a catch-up synchronize - how long does it take? how much did it synchronize?
- wait another day
- run another catch-up synchronize - how long again? how much copied again?
- plan for time when old NetBackup is quiet
- keep running daily catch-up synchronizes
- at the appointed time....
- deactivate all backup policies and all SLPs
- take a final backup of parts of old master that you might need on new master
- take a final catalog backup of old master
... and while that is running, run final catch-up supynchrinize of disk pools
- hopefully the catalog backup will finish sooner than the synchronize
...as soon as catalog backup finishes, start copying it to new master
- if it's really big catalog - why not send the catalog backup to a DSU on new storage - so that it's immediately available when you re-attach new store to new master
- when final synchonize has completed
- cleanly detach new storage from old master
- make a note of which NetBackup services are running on old master
- stop NetBackup on old master
- if Windows, then disable all NetBackup sevices
- take a note/copy of hosts file from old master
- make a not of "computername" of old master
- if Windows - evict computer from domain, and change "computername" of old master
- change all old IP addresses on old master (all of them!)
- shutdown old master
- change name of new server to use exactly the same name as old master
- change IP addresses of new master to match old master
- if Windows then re-add computer to domain
- recreate hosts file if need be
- install NetBackup server on new master
- re-create touch and value files and scripts
- stop NetBackup
- restart NetBackup
- is it up Ok?
- attach new SAN based disk pool to new master
- give it drive letter same as was used on old master
- perform catalog recovery
- test restore from a backup known to be residing in disk pool.
- re-enable backup policies and SLPs
There could be quite a bit more to add.
Really it's all about preparation.
In my experience the critical task is this one... Prepare a very detailed plan, and roll-back plan. if you don't put any effort in to planning and just go for it - it is highly likely, in fact near certain, that you will fail, and you could be putting business data at risk.
N.B. a NetBackup catalog can only be restored to the drive letter and/or path that it came from..
Look for any and all NetBackup touch and value files that you may need to re-create on new master.
Have there been any OS custom tweaks in the past, which you may need to re-implement on new master?
Do you need to copy over custom NetBackup notify scripts?
Depending upon your NetBackup version, you may need to copy SLP lifecycle parameters file.
What about custom site specific scripts and tools?
Have the required kits and manuals ready on new master?
Open pre-emptive case with Symantec Support - and share your detailed plan with them beforehand, via the support case.
You might not be able to, but it might be worth testing catalog recovery in sand-boxed VM with no IP routes to production network - to familiarize yourself with the process.
BTW, this is not meant to be an exhaustive list - there's plenty more you can/could/would/should/will do (and I'm sure some 'must do' items too that I can't think of right now) - this is just to get you on your way with planning. Good luck, but with proper planning you won't need much luck.
HTH