Catalog Recovery to a different Windows server

[LT2013]

I installed a new environment, running 7.6 on single Windows master/media server (call it NBmaster). I need to test catalog recovery to a different server, NBmaster_dr.

I've read several posts the state the target host for a catalog recovery must have the same hostname as the source. However, can I alias the hostname of my master to the DR target's IP address, and be able to recover my catalog? I would have thought this should work but I'm having some issues after a server reboot.
 

[Marianne · Accepted solution]

The requirement is that server name must be the same.
IP address can be different as this is not contained anywhere in the databases.

Emm database will not start up if hostname is different from EMM server name.

Hostname alias will not help.

[RiaanBadenhorst · Accepted solution]

What you can do is leave it in a workgroup, so its not in AD, so it doesn't conflict with current system. Just make sure name resolution works via hosts file.

[SymTerry]

From TECH58358: Recovering a Master Server at a disaster recovery site from a catalog backup requires the same topology.

When carrying out a full catalog recovery to a Master Server at a disaster recovery site using a catalog backup the disaster recovery (DR) Master Server must have the same "topology" as the original Master Server. 

For standalone Master Servers this means:
1. The DR Master Server must be running the same operating system and NetBackup version as the original Master Server
2. The DR Master Server must have the same host name as the original Master Server
3. NetBackup must be installed in the same location on the DR Master Server as it was on the original Master Server

NOTE: This requirement only applies to full catalog recovery.  Partial catalog recovery from a catalog backup to a Master Server with a different name or cluster configuration (but not a different operating system) is possible but may require additional, post recovery work

Also please have a look at A Guide to Site Disaster Recovery Options, TECH66060

[INT_RND · Accepted solution]

You need a DR test environment that is separate from the production network to avoid IP conflict. Traditionally this was done with a complete set of identical hardware. It's much easier to build a test network within Virtual Machines nowadays.

Create an isolated subnet. You can either manually configure all the IP settings and host files in a block or you can run a DHCP\DNS server configured for your DR testing. Just make sure there are no routes between the production and DR environment. If you target the hostname, for example, and you get a reply from the production DNS server then you will be overwritting live data thus creating a real disaster.

Make a full DR plan on paper. Map the architecture. Lay out all the steps need to go from bare metal to restoring production servers. Then follow the plan that you wrote in your DR lab updating the documentation as you go. The end goal is not only to prove that it can be done but make it a simple step by step process. Your goal is to minimize down time.

[LT2013]

Thanks for the replies...and the workarounds.

I've been working with NB since version 3.4 and while there has always been a procedure for DR recovery, DR testing has always been a challenge. Particularly when you simply want to test your recovery procedures on a different server without having to go to a DR site, change IPs/hostnames, etc...

I know AIR can mitigate some of this by having a separate NB domain where you can replicate image metadata, but that won't replicate tape image metadata :(

[INT_RND]

You don't need to replicate tape images, generally. The catalog backup should be kept with the offsite backup tapes. This strategy is for cold site recovery. If you have a hot site then you should be using MSDP pools with AIR. If you really want to ship tape to a hot site you can import them as soon as they are recieved. The import process is fairly quick.

[RiaanBadenhorst]

What challenge? Install the OS, install NetBackup, recover that catalog. What is challenging about that?

[Steven_Moran]

@Marianne, why would DNS aliases not work?

[LT2013]

Riaan,

The "pain" is that I simply want to certify my procedures for DR (which in this case also include MSEO), not have a full blown DR test. So i have to wait on other teams to process my request, make the DNS/hostname change, etc... So while the process itself is smiple enough, the "red tape" around it makes it a challenge.

Maybe it's because this is a windows platform, but I've done things in the past to "fool" NB by deleting resolv.conf, and using /etc/hosts for hostname resolution (hence I thought the aliasing might work).

Not knowing the internals of NB, it would be nice to segregate the NB domain/EMM DB name from the host that it resides on. So you could load an environment on a warm standby server without changing hosts/IP.

[RiaanBadenhorst]

You can do that if you don't put the servers into your AD domain, that's when it will conflict. By the way, NBU doesn't need to be, as you would have seen in your linux/unix experience. But I understand that red tape involved. You should make look at the recovery without import option

http://www.symantec.com/docs/TECH28722

[Marianne]

Simply because 'bpclntcmd -self' will default to OS hostname.

Your DR server should not be on the same network/AD as production master server.