Showing results for 
Search instead for 
Did you mean: 

Re: DR Site

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.

Re: DR Site

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.

Re: DR Site

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?

Re: DR Site

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.