Yes, they are on the same campus. And I agree, if we were in an earthquake zone, that wouldn't be far enough away.
But that's really a management decision - what disaster coverage do you require? Currently, our copy pool tapes are stored in the other building, and management believes that provides sufficient distance. We are covered for fire, flood, explosion. We are not in an earthquake or hurricane zone. We are NOT covered for a regional power outage such as would occur in a florida-like hurricane zone. But in that case we can take our tapes and move them elsewhere, and what we lose is time, not data. If this were a commercial enterprise, that time would be a larger concern. As with any DR situation, you have to figure out YOUR exposures and your requirements for resolving them. With our traditional methods of creating primary pool tapes onsite and moving copy pool tapes offsite, you have the slow/uncollocated restore problem. All I am suggesting here, is if we can use newer technnology to overcome the communicaiton limits, and think outside the box a bit, we should put the TSM library offsite, and keep the copy pool tapes onsite. That would provide equal coverage and eliminate the slow/uncollocated restore problem. (AND you eliminate the up-front time required to rebuild the TSM server.) Just something to think about. -----Original Message----- From: David Longo [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 1:18 PM To: [EMAIL PROTECTED] Subject: Re: DISASTER Client Restores Slow I would say that technically, that sounds good. Except for one thing. How close are the two buildings? I wouldn't want all my eggs on the same campus. David Longo >>> [EMAIL PROTECTED] 05/17/02 12:49PM >>> An idea to think about: We are looking at the possibility of changing our hardware config to take care of this issue. We are considering MOVING our TSM server out of the data center into a different building. With today's fiber connections the technology exists to do that. The primary pool tapes would stay in the tape robot, in bldg 2. Racks in the data center would be used as the "vault" for the copy pool tapes. If we lose the data center, the TSM server stays up and is ready to go, with collocated tapes available for restores. If we lose bldg 2, who cares, our data center is OK. We can take our time rebuilding a TSM server. The technology is out there so that we all probably start thinking about solutions like this. If all you have to work with is a DR site where you have to rebuild from scratch, this idea won't help you, I know. In that case I think backupsets + incremental restore-by-date to current is probably the fastest way to go. Creating backupsets periodically can be automated. It's not reasonable to do for ALL your servers, but for your most critical ones it's a fine idea. ************************************************************************ Wanda Prather The Johns Hopkins Applied Physics Lab 443-778-8769 [EMAIL PROTECTED] "Intelligence has much less practical application than you'd think" - Scott Adams/Dilbert ************************************************************************ -----Original Message----- From: Walker, Thomas [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 11:08 AM To: [EMAIL PROTECTED] Subject: Re: DISASTER Client Restores Slow And using another backup solution won't result in many tape mounts as well? TSM might be more mounts than others, but you only have to do one restore. Remember, not using incremental forever means that you must resotre a machine at least two times. How about using backup sets if time is that much of an issue? If you have a couple hundred servers, I assume you have enough tape drives to make this feasible? Using, say 5 drives, to restore 100 clients is probably a pipe dream. Also, do you run multiple servers? You can easily pass the bus throughput of most machines when trying to restore this much data. I guess what I'm saying is that people argue that tsm mounts a lot of tapes and appears slow during DR restores, but in reality, the people that complain are usually trying to restore a lot of clients on a severely under-sized configuration. I think matching your DR hardware setup to your production setup is not a good idea. Most production setups are for speed in backing up. This usually means they are not optimized for restore speed. Also, prioritizing restores is key. I've cut DR times from originally 2 1/2 days of nightmare when I came here to about 17 hours with a fairly big setup. In other words, don't just start all restores at once and let 100 clients fight for 6 drives. Of course it's gonna look slow! -----Original Message----- From: Talafous, John G. [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 10:34 AM To: [EMAIL PROTECTED] Subject: Re: DISASTER Client Restores Slow I am sure TSM will wait. And while we're on this subject, we are looking at Disaster Recovery plans and the path we must take using TSM to recover a couple hundred servers. It looks bleak. We are finding that, due to incremental forever backups, recovery times are extremely long because of tape mount after tape mount after tape mount. In a real disaster, we expect to take an entire day or more to recover a single server. With a limited number of tape drives the recovery time required for 100 servers could take weeks. Has anyone else run into this dilemma? What is TSM's direction? How can I speed up the recovery process? John G. Talafous IS Technical Principal The Timken Company Global Software Support P.O. Box 6927 Data Management 1835 Dueber Ave. S.W. Phone: (330)-471-3390 Canton, Ohio USA 44706-0927 Fax : (330)-471-4034 [EMAIL PROTECTED] http://www.timken.com This e-mail including any attachments is confidential and may be legally privileged. If you have received it in error please advise the sender immediately by return email and then delete it from your system. The unauthorized use, distribution, copying or alteration of this email is strictly forbidden. This email is from a unit or subsidiary of EMI Recorded Music, North America "MMS <health-first.org>" made the following annotations on 05/17/02 13:33:33 ---------------------------------------------------------------------------- -- This message is for the named person's use only. It may contain confidential, proprietary, or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it, and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Health First reserves the right to monitor all e-mail communications through its networks. Any views or opinions expressed in this message are solely those of the individual sender, except (1) where the message states such views or opinions are on behalf of a particular entity; and (2) the sender is authorized by the entity to give such views or opinions. ============================================================================ ==
