The approach I've found usefull is to back into your TSM configuration.
Which systems are most important to recover, and is there a preferred
order?
Answering that may lead you to having co-located offsite copys; it may
also lead to having several off-site pools -- which require multiple
on-site pools -- which may require multiple disk pools and will require
multiple management classes.
Are there servers we will NEVER recover at D/R?
If so, you may not want to send copies offsite at all (we have systems
that can be recovered by cloning production data, so the test database
never gets copied for off-site) -- requiring still more management
classes.
Also, for the most part you do NOT want to watch the restore scroll on
the screen. We have one system that can restore in 20 minutes -- but
there are sooooo many files that the list will scroll for three hours.
Redirect the output to a flat file and tail the flat file. (The Sungard
AIX systems use version 4 or version 5 HMC, and the console window will
be driven by a 9600 bps connection on the version 4 systems).
We also run archives of the non-databse application file systems -- the
executables and such -- once a month. We retrieve the archive and then
do point-in-time restore of the filesystem. This has proven to be
significantly faster than just the PIT restore. (And another storage
pool set, and more management classes . . .)
Also, depending on your HA environment, you may find it works better to
restore your database before rebuilding the HA environment. Get the
servers up from sysback/mksysb, restvg the empty volume groups, restore
& recover the database, shut it down, configure HA, run an off-line
database backup, and then start for normal business.
In our recovery (mid-size manufacturing) we never rebuild the HA cluster
during the test runs. We might rebuild in the event of a true disaster,
but the jury is still out on that. In your case, I'd recommend
rebuilding HA, but probably after the recovery as I said above.
Good Luck!
Tom Kauffman
NIBCO, Inc
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Nicholas Rodolfich
Sent: Wednesday, September 05, 2007 4:05 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Insight into improving restores needed
Hello All,
Thanks for your help!
I work at a medical institution and there is a big push to get our DR
procedures in order. We will be using a Sungard facility for our DR
activities and we will have to restore 4-6 AIX servers (2 HA clusters 1
DB with 1Tb and one apps on another cluster) and 20-25 Wintel platforms
with various applications, DBs, Novell, etc.
We have a 3584 Library with 16 drives (8 LOT1 and 8 LTO2) and a 55A
with 4CPUs and 12Gb RAM. Gb NICs and will have like equipment at the DR
facility.
Some tests have revieled an extended time to restore due to many
volumes being loaded to perform a restore. I am looking for some
empirical strategies, white papers, advice, etc. to help me improve this
situation without loads of money of course! I am not ruling out any
method including backup sets, archive schedules, collocation, etc.. I
can't seem to find what I need from IBM websites regarding the gotcha's.
I need the "fastest way" shy of a $10M hot site strategy so I am going
to the mountain! I appreciate you help!!
Nicholas
IMPORTANT NOTICE: This message and any included attachments are from
East Jefferson General Hospital, and is intended only for the
addressee(s), and may include Protected Health (PHI) or other
confidential information. If you are the intended recipient, you are
obligated to maintain it in a secure and confidential manner and
re-disclosure without additional consent or as permitted by law is
prohibited. If you are not the intended recipient, use of this
information is strictly prohibited and may be unlawful. Please promptly
reply to the sender by email and delete this message from your computer.
East Jefferson General Hospital greatly appreciates your cooperation.
CONFIDENTIALITY NOTICE: This email and any attachments are for the
exclusive and confidential use of the intended recipient. If you are not
the intended recipient, please do not read, distribute or take action in
reliance upon this message. If you have received this in error, please
notify us immediately by return email and promptly delete this message
and its attachments from your computer system. We do not waive
attorney-client or work product privilege by the transmission of this
message.
|
