DR Site

[Kunalgoel]

Hello Team,

master server OS: Solaris 10

Master server NBU version : 8.1.1

we are planning to build our DR site. 

1. we will build master server at DR site with same OS and version

2. will install nbu binaries on newly build master server with same version

3. we will configure all policies at DR site as inactive state

4. we will create same db mount points (nbdb, nbemm) at DR site and that mount point will be in real time synch

5. if our primary site goes down then we will re-name the secondary master server (same as primary master server) and run the show.

6. if we need to perform any Test DR restore, in that case also we will re-name the secondary master server (same as primary master server) and perform or we can perform import of that particular image and do test restore.

Is this plan looks good? kindly suggest. 

any other DR plan and suggestions are welcomed

[Mouse]

For the first question, yes you take XYZ and make it floating, basically that XYZ IP/Hostname (in reality you can have even a different IP, just keep the host name the same) will now belong to NBU and will alive on the active NBU master. You'd need to give another IP and hostname to the Solaris physical box and that can easily be XYZ-1/XYZ-2.

To make the IP floating you add one more IP to the network interface through either interface alias or a virtual interface. When you need to move the master, you shutdown it in Prod and pop it up in DR.This is what a clustering software would do for you automatically but the same trick can be done manually and it's not rocket science.

Now for the last question, while you can migrate from a standalone NBU install to clustered one, it's not free and there are no end-user tools available for it. This procedure requires a qualified and authorised consultant to perform a procedure through CatMan (proprietary tool) to modify the database and migrate to the cluster.

[Marianne]

In addition to @Mouse 's excellent post - just be mindful of NBU's host cache that only refreshes every 1 hour.

So, if NBU is started up immediately (or shortly after) activating the virtual IP address and virtual hostname, then emm will fail to startup because it does not know about the new hostname.
The fix is to run 'bpclntcmd -clear_host_cache' before starting NBU.
Better - add the command to NBU startup script.

[Dav1234]

Hello Mouse/Marianne,

Thank you for the information.

If catalog recovery has to be done on DR site then the FS structure/mount points should be same as PRD server on DR server?

[Marianne]

Not really.
You need to ensure that all mount points and symbolic links are the same before you install NBU in DR.
Or else create symbolic links if NBU is already installed to different mount points.

NBU will restore data to folders that correspond with original master.
If your mount points are different on the DR site, then the restore could fill up your root or /opt partition (/opt is the default on Solaris).

Example :
You have added a mount point on Prod master that you mounted as /opt/NBU. You specified /opt/NBU as installation path. All binaries and catalogs will be created there.
You may have added another mountpoint for catalogs - /opt/cat and created a symbolic link in normal path for /opt/cat.
(Relational database will still be in /opt/NBU if you did not move it to /opt/cat.)

If the mount points do not exist in DR, then catalog recovery will create folders in /opt for 'NBU' and 'cat' and restore there.
If /opt is the default small partition, it may fill up during restore.

If I am not mistaken, all of this is documented in NBU Troubleshooting Guide in Disaster Recovery chapter.