> Since we restored the DB from our production system, it expects to find
> the same libraries and associated AIX devices in the PATH definitions. But
> those devices are no longer valid. Furthermore, once I connect the
> drop-shipped library to the recovery server and run cfgmgr, I end up with
> AIX devices at rmt1-rmt4. Those AIX devices are referenced by the
> definition for Primary #1. Also, since it will not be an IBM library -
> probably - when I create the lb/mt devices they won't match the ones
> associated with our production copypool.
I'd say that you should consider the data 'which rmtN goes with which library'
to be eminently transient. Ditching the paths and making new should be an
uncommon but unworrying operation, so don't worry about making it look similar
or different, just make it work. :)
You might prefer to set up a whole new library (e.g. DRCopy..) and just
reassign all of your DR stgpool devclasses to use that library.
> I know I can "chainsaw" my way through the TSM device and path definitions
> to fix this situation. But what is the BEST PRACTICE for fixing all this?
I'm not sure what "chainsawing" means in this context, but completely
redefining your paths when you've completely changed your hardware doesn't
seem excessive to me.
> Please remember that at some point, the disaster will end and we will want
> to shift back to our production system at our normal company site. We don't
> want to orphan any new data that was backed up while in DR mode.
Probably the best way to simplify reintegration is to make sure that -new-
data gets stored in different stgpools than the data you're recovering. Then,
when you have your normal operations back, you can move data from the
temporary DR-installation stgpools back to normal stgpools.
This might be made easier if you create the new stgpools as "remote volumes",
even if they're physically local in your DR facility. Then, when you move the
production server back to the home site (which will, of course, be another TSM
server disaster-recovery drill, just one you can schedule) you can just set
the NEXTSTGPOOL for the now really remote stgpools to your normal production
stgpools. Then, drain them as time permits
- Allen S. Rout
|
