I’m running networker version v8.2.4 on a windows server 2008 R2. Our external DR environment has the same physical infrastructure and also same OS version and same hostnames for clients and the networker server.
Does this DR site have the same networking setup?
If your production environment depend on DNS for name resolution, are the DR’s DNS servers all populated with the same host info as the production server?
If the DR’s DNS is not setup, does each of the DR NetWorker hosts all have their local host file populated with the needed hosts and ip. addresses?
Many people performing DR tests has encountered seeing the NetWorker server starting up the NetWorker server application very slow or even appear hung because host name lookup was not defined at the DR site. The lookup happens because when nsrd is started, it reads the nsrdb database, and then afterwards when nsrmmdbd opens and reads the media database. In both cases, essentially, if it finds a hostname (or FQDN), it will perform a name lookup for its IP address. And if it fails, it will retry a few times before finally giving up.
This behavior can also happen in production sites if the name lookup service is unavailable when NetWorker server is started.
The more hosts that are not resolvable, the longer the NetWorker server startup will take.
During previous DR testings on this external environment, we were using the scanner command to scan the tapes and rebuild the media database and indexes, but this is taking 2 days or more to complete.
In a pure DR scenario, after installing NetWorker in the DR server, you need to locate the volume that has the most recent NetWorker bootstrap backup. And if you have the ssid of that most recent bootstrap, then even better. With that, then all you have to do is to create the NetWorker device that can read that volume, put that volume into that device, and (prior to nw 9) run mmrecov. After that, you stop nw, make an online backup copy of res.R and mm, replace res with res.R, then restart NetWorker and complete the recovery. Note: after the recovery is complete, you should also scan that same bootstrap tape.
If you only know the volume that has the most recent bootstrap, then load the tape and use “scanner -m” so that it can catalog the tape. “mminfo -avot (volume)” will then tell you what is on the tape, and you can then find the bootstrap info from that output.
If you do not know which volume has the most recent bootstrap, then unfortunately you will need to scan each volume until you locate it. You should only need to scan tapes until the bootstrap is located.
After the bootstrap is recovered, you can then recover some or all of the client file index using: “nsrck -L7”.
EMC Networker Disaster Recovery Guide suggests I should backup the media database and client indexes to a single tape…
Ideally that would be convenient for DR purposes, so that all you would need is minimal set of tapes to recall for recovery. This can be achieved by creating a pool to store index and bootstrap backups. To create a set of volumes that will contain the bootstrap and index:
– label a new tape with the pool you will use to hold the bootstrap
– load that new tape so that new tape will be used
– create a NetWorker Group that has all the clients that you want to backup their client file indexes. Or just add the clients used for the DR testing.
– backup the bootstrap and indexes with: savegrp -O -l full -b (pool) (Group)
The “savegrp -O” will backup the client file index databases first before finally backing up the bootstrap.
In a pure DR scenario, you would need to rebuild your NetWorker server, and possibly your networking infrastructure. For your DR testing, I would recommend creating a text file containing all the hostnames and ip’s in your NetWorker environment. Save that file to a memory stick, and bring it along to the DR site.