cancel
Showing results for 
Search instead for 
Did you mean: 

Restore from prod. to dr. using different nbu server

Michael_Glas_2
Level 3
Hello,

I am having lots of problems performing a restore from a different master that made the backup and this HAS to be restored tomorrow.

1. Cut network link between production and disaster recovery site.
2. Rename dr system to reflect hostname in production.
3. Copy image files from prod host to dr host.
4. Use bprecover to restore the catalog from the image files.
5. Start Netbackup gui but 2 services (request manager & db manager) wont start.
6. Start preparing restore but get error message "ERROR: cannot connect on socket" - selected hostname for server, original client name for source client and the destination host.

Any ideas on how to progress this please.

Many thanks,
Michael.
3 REPLIES 3

Ranjith_Kumar
Level 3
Hi

Enclosing the solution for ur query.

Actually veritas wont recommend to use the IDR when trying to perform for a differnt Host (master server).

Limitations of DR.

1. Bprecover wont work when you have the source catalog of primary host & trying to recover it for other host.

2. should not try to copy all the catalog files like volmgr, Var etc directly from one source to other differnt host server

3. Hardware should be identically (library) if not, need to manually reconfigure the storage devices.

Procedure for DR with a differnt host master server.

1. Install the same Operating system (eg: win2k), or whatever it was in the primary host.

2. Install the service pack (sp4) or similar setup.

3. Install the Veritas Netbackup 4.5 fp6 or mp6 (same as of Source server)

4. Dont try to recovery the catalog for the new host server, it will thru error & it is highly not possible to recover it thru bprecover command

5. you should try to manage to have the catalog files some how in harddisk.( if u dont have any such thing, you have install the NBU with the same name, use the bprecover & bring the catalog to disk in some test machine)

6. Copy the below folders from source disk to new host veritas fodler same location
Nebtackup\db\images, -- Clients backup images directory
Netbackup\db\class ------ All previous policy created in the source host

7. Once this is done...create a new volume pool and do the inventory of ur tapes & move it to the new volume pool. This is to ensure the tapes for restoration purpose.

8. So ur now fine with the NBU, with the storage device(newly configrued), same polcies, tapes, etc.

9. Go to Master server host properties --> General server --> media host override -> define the old master server & new master server name

10. You will be able to see al the old backup images for all the clients including the old master server thru backup/archive/restore console from master server But dont try to restore the C:\ of ur old master server backup to new master server . it will create lots of issues & will landup in blue screen surely. except this master server c drive data, u can restore all the backups for all the clients anytime

11. This media host override settings will ensure to restore the backups successfully with the new master server

This is the exact step you need to follow

Rgds
Ranjith -Netbackup 5.0 certified specialist

zippy
Level 6
Mike,

Backup tape was done on Master_server1 and you want to use Master_server2 to do the restore correct?

in /usr/openv/volmgr/vm.conf file

stick

FORCE_RESTORE_MEDIA_SERVER = Master_server1 Master_server2

JD

Michael_Glas_2
Level 3
Thanks very much for your answers - learned something from that. However because of need to have this done today i stayed till the problem was fixed. First up the /etc/hosts under Windows was wrong (i am a Unix person and dont know much about Windows but the Windows ppl know less about NBU). After fixing this all the processes started. Then i discovered there was a dns problem. Dont want to get into it but had to rebuild the dns and exchange servers. After that the tapes, file systems and systems could be seen. Now i presume the restores to work which are about to commence.

Thanks again,
Michael.