cancel
Showing results for 
Search instead for 
Did you mean: 

After restore catalog backup, error on nbdb restore

DexterASG
Level 2

here's the scenario -- moving the old nbu (2008) to new server (2012) 

catalog backup was completed from the old one and the cname from the old one is moved to the new server (nbu master and emm db uses uses a cname)

reconfigured everything ensuring that the new one sees the media server by simply adding it to the media server -all OK and connected

copy the image file and the catalog dot back file to the new one and ran a restore of the catalog 

catalog was restore but having issues with the fail to recover nbdb but when I checked the nbu DB it is there (error 5)

installation path is the same with the new server, was able to see all the policies but not able to view the volume groups and pools same as the old one which are on offsite tapes 

i appreciate your help on this been working on this for 2 months already 

thanks!

 

4 REPLIES 4

DexterASG
Level 2

here's the error 

 

19/11/2019 2:21:18 PM - Info bpdm(pid=480) started           
19/11/2019 2:21:18 PM - started process bpdm (480)
19/11/2019 2:21:18 PM - Info bpdm(pid=480) reading backup image         
19/11/2019 2:21:18 PM - Info bpdm(pid=480) requesting nbjm for media        
19/11/2019 2:21:18 PM - Error bpdm(pid=480) NBJM returned an extended error status: Disk volume not found (2067) 
19/11/2019 2:21:18 PM - requesting resource @aaacG
19/11/2019 2:21:18 PM - Error nbjm(pid=4348) NBU status: 2067, EMM status: Disk volume not found   
19/11/2019 2:21:18 PM - Error nbjm(pid=4348) NBU status: 2067, EMM status: Disk volume not found   
19/11/2019 2:21:20 PM - Info bpdm(pid=480) requesting nbjm for media        
19/11/2019 2:21:20 PM - Error bpdm(pid=480) NBJM returned an extended error status: Disk volume not found (2067) 
19/11/2019 2:21:20 PM - requesting resource @aaacG
19/11/2019 2:21:20 PM - Error nbjm(pid=4348) NBU status: 2067, EMM status: Disk volume not found   
19/11/2019 2:21:20 PM - Error nbjm(pid=4348) NBU status: 2067, EMM status: Disk volume not found   
the requested operation was successfully completed(0)

DexterASG
Level 2

nbu.PNG

DexterASG
Level 2
15:55:06 (26.001) FTL - socket read failed
15:55:06 (26.001) INF - TAR EXITING WITH STATUS = 23
15:55:06 (26.001) INF - TAR RESTORED 0 OF 1 FILES SUCCESSFULLY
15:55:06 (26.001) INF - TAR KEPT 0 EXISTING FILES
15:55:06 (26.001) INF - TAR PARTIALLY RESTORED 0 FILES
15:55:06 ERR - Failed to execute command E:\Program Files\Veritas\NetBackup\bin\bprestore.exe -w -T -X -C nbumaster01 -t 35 -p NBU_Catalog -e 1573614597 -priority 90000 -L "E:\Program Files\Veritas\NetBackup\Logs\user_ops\A09806401\logs\20191120155322.log" / on host nbumaster01 (24)
15:55:07 (26.001) Status of restore from copy 1 of image created 13/11/2019 2:09:57 PM = socket write failed
15:55:07 (26.xxx) INF - Status = socket write failed.

Nicolai
Moderator
Moderator
Partner    VIP   

I don't think you can use CNAMES, this was least the case with NBU 7.x

if doing DR, name of old master server and new master server must be the same, there are references in the EMM database that is not renamed as part of DR restore.

It looks like the disk storage unit name is not the same. Netbackup uses external and internal labels. In this case the disk storage unit from the old master is called  @aaacG. But that disk storage unit doesn't exist on the new master server, therefor the restore fails.

You can use the Netbackup command nbdevquery to list disk storage units and their internal names:
https://www.veritas.com/content/support/en_US/doc/123533878-127136857-0/v123549725-127136857

It is expected disk pool names to be diffrent after a recovery, but according the documentation below, that should be handled during catalog recover for the following devices;

  • An AdvancedDisk disk pool

  • A Media Server Deduplication Pool (MSDP)

  • An OpenStorage device

https://www.veritas.com/content/support/en_US/doc/15179611-127304775-0/v95647799-127304775