Bobby,
You plan sounds very good, but one question. Why not just replicate
/usr/openv/netbackup/db/images to the alternate master? Then you would
not even have to recover the image db. Just put tapes in, inventory, and
restore. Of course you couldn't be backing up a client with the same
exact name in both locations, but I doubt your doing this anyway.
Another downfall to this is that is isn't supported, but it works! This
is how we do DR for one of my accounts for both Windows and HPUX.
Thanks,
Kris
-----Original Message-----
From: veritas-bu-admin AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu] On Behalf Of Bobby
Williams
Sent: Saturday, December 10, 2005 7:18 AM
To: 'Ed Wilts'; 'List Veritas List'
Subject: RE: [Veritas-bu] Disaster recovery configuration
Several scenarios (since I don't know how much budget you have).
Since you are considering a global cluster, I will assume that you have
a hefty net pipe.
(some of the steps below are discussed in a white paper from Veritas on
doing DR without importing tapes. You can find it on the web site, but
I am at home and my copy is on my desk at work in my DR manuals.)
We are doing this process with 2 data centers. Each data center is the
DR site for the other. Centers are 100 miles apart with a big pipe
between.
DR tapes are sent to an offsite company (metallic sound big hill). Each
site has a Master server (same OS has to be on both master servers) and
robot that backs up local servers. (although it is obvious to some, the
robots need to have compatible tape devices) Each master does a database
backup to disk each day (as well as tape). Each master has a policy to
back up the alternate master's disk based database backup.
So, now I have a copy of the alternate master's database, safe copies of
DR tapes, and hardware to restore. (I last did a DR test on this in
August 05 on 4.5FP6).
Now, the DR happens. Assuming that key people survive (and most DR
plans always assume this), everyone gets in the car and waits in traffic
as all of the other survivors try to get out of town (of course everyone
is going to let you through because you have to do your DR recovery and
it is more important than them saving their own life). Now you call
your offsite vendor and have them send your DR tapes to the DR site.
(Oops, they did not have any employees show up for work). Anyway, you
get your tapes and your self to the DR site.
All you need to recover your data is the
/usr/openv/netbackup/db/images/{client to be recovered} directories.
(Everything is there to recover, you do not need the volDB.) Write
protect your tapes from the failed site (since you don't have the volDB,
you can not write to these tapes) and put them in the robot. Create a
pool that will have only your DR tapes in it (will make your sanity
better) Inventory the robot to get the updated media list (I did not say
to inventory the tapes).
Put a FORCE_RESTORE directive in bp.conf so that you have the right
configuration, and also put a "NO_RESTRICTIONS" file in the
/usr/openv/netbackup/db/altnames directory. And while all of the Unix
admins are running around trying to figure out who forgot to plan for
having extra hardware on hand to recover to (that is a requirement for
DR, YOU HAVE TO HAVE A SERVER TO RESTORE TO), you need to promote all of
your offsite tape images to be the primary copy (if you don't, you will
be waiting to mount all of those tapes that melted) You are now ready
to restore your critical servers.
ANOTHER OPTION: for the folks that can't have the above scenario.
(Remember, you are not in violation of your license by using the
software key from the master server that melted).
Do the same thing above, after you rebuild a system to be the master.
You can still back up the database across a WAN, or make sure you send a
copy offsite EVERY TIME you pull tapes.
I last tested the second option in August 05 on NB 5.1MP2.
I frequently import tapes from 4.5 masters into a 5.1 database, so that
should not cause anyone an issue.
You can not do the above process on different Architecture systems. I
know that Sun master to Sun master works. I know that Win master to Win
master works. If you have masters that have non-compatible file
systems, you are not going to be able to just restore the image
database.
Bobby Williams
2205 Peterson Drive
Chattanooga, Tennessee 37421
423-296-8200
-----Original Message-----
From: veritas-bu-admin AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu] On Behalf Of Ed Wilts
Sent: Friday, December 09, 2005 5:06 PM
To: List Veritas List
Subject: [Veritas-bu] Disaster recovery configuration
We're starting the process of building out another data center as a
disaster recovery facility. One of the things I don't yet know how to
configure is NetBackup. We've got a single Solaris master server today
and will obviously be putting a Solaris backup server at the DR site.
We will also have a tape library there that will be doing regular
backups as well as handle any disaster recovery restorations.
Should I do a global cluster configuration for NetBackup? If not, and I
configure the 2nd server as just a media server, how do I promote it to
be a master? What support mechanisms are there to keep the catalog up
to date at the DR site?
I've had a quick look through the Veritas web site but haven't found
anything that documents best practises for cases like this.
Any suggestions would be greatly appreciated.
Thanks,
.../Ed
--
Ed Wilts, Mounds View, MN, USA
mailto:ewilts AT ewilts DOT org
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
