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:[EMAIL PROTECTED] On Behalf Of Nicholas Rodolfich Sent: Wednesday, September 05, 2007 4:05 PM To: [email protected] 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.
