MSDP catalog backup does not protect dedupe data, but the dedupe meta data.
Meta data is all the information required, to know where the unique data resides in the MSDP pool. Without catalog information all other data in the MSDP disk is worthless.
Please save the MSDP catalog backup on another storage unit, that the orginal MSDP pool, else you have a true catch 22
Be aware youre are at risk as long as the replication hasn't taken place. What about backing up the MSDP catalog to the other MSDP pool first and then do a replication back ?
Also - you need may need to specify what copy to restore since Netbackup always will try to restore the primary copy.
Fortunately we have pretty much good success rates with replication & its been happening on daily basis so we should be having 2 copies on 2 different locations everyday.
We can not duplicate it first since we only have single MSDP pool configured on most of the master servers (Sinlge master/meddia servers)
You are correct as netbackup always seeks for restore from copy1, but is that something (Copy1/Copy2) we can switch while performing the restore?
Specifying the copy number vary dependng on application. If it is bprestore command you can specify the copy number, so can oracle RMAN backups. But if it is too GUI based you may need to promote a seconday copy to the primay copy using the bpimage -npc command. I never had to restore the MSDP catalog, so I don't know what logic Veritas is using. But maybe try it out on a lab system to see what it is restoring a secondary copy if the primary MSDP is down ?