Re: DISASTER Client Restores Slow
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Talafous, John G. 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? Several things should be done when planning TSM and disaster recovery: 1. Use a disk-based directory management class. It makes dir scans *much* faster. 2. Collocate data from your most cirically important machines; or, 3. If you're using TSM 5.1.x, consider use of the MOVE NODEDATA command. 4. Plan your disaster recovery scenarios, and practice them (*before* you have to). 5. Buy enough library (and enough tape drives) to handle mass restores. The slower the mount time on your drive, the more drives you'll need. 6. If your IS department lacks sufficient TSM experience to integrate it into your DR plans, hire a consultant to help you get it right. And if your SLAs can't stand significant downtime ( 2-4 hours), then no backup/restore software will do the job. As our Sister Wanda P. has preached before, you need to be looking at clustering/real-time mirroring/HACMP/whathave you. -- Mark Stapleton ([EMAIL PROTECTED]) Certified TSM consultant Certified AIX system engineer MSCE
Re: DISASTER Client Restores Slow
It is up to you how to set-up the TSM server policies. If you prefer to save space on off-site tapes you have to pay a price and it is many tape mounts. If you want speedy restores as from primary tapes you can collocate off-site pool as well. An example: - business critical servers - primary collocated by filespace, copy collocated by node - important servers - primary collocated by node, copy not collocated - other servers (or notebook of financial manager saving on tapes :-) - not collocated both primary and copy Zlatko Krastev IT Consultant Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] Sent by:ADSM: Dist Stor Manager [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: 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 CompanyGlobal 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
Re: DISASTER Client Restores Slow
Two thought on your comments. First: If restores are taking a long time due to the amount of data being restored, you could look at HSM. If your target client is a Windows 2000 machine look at OTG DiskXtender. These products will move files, based on criteria such as age, size, and/or file type, to tape and replace them with a very small tag on disk. When you recover your client only the tags are restored. This provides significant performance to recovery. Second: With the size of today's disks, recovery using tape is simply a task that requires time. An option is to use remote disk storage. Having a real time or almost real time set of remote disks makes recovery of even the largest sites a few hour task. Lee Fletcher Network Project Integrator Ameren Callaway Plant 573-676-4106 [EMAIL PROTECTED]
Re: DISASTER Client Restores Slow
Has anyone had a look at a new feature in the TSM5.1 server code that gives you the facility to consolidate a nodes data - either on filespace level or node level? This will address the multiple tapes that a client's data can end up on over an extended period of time. For those that do not know about it, it is a new admin command called move nodedata Cheers Christo -- 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 CompanyGlobal 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 __ The information contained in this communication is confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorised to receive it. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful. Absa is neither liable for the proper, complete transmission of the information contained in this communication, any delay in its receipt or that the mail is virus-free.
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 CompanyGlobal 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
Re: DISASTER Client Restores Slow
It will wait for the tape. Normally that is. If there is a problem with the tape (access=unavailable for instance) it will skip it. If another client is currently restoring from this tape, it will wait till tape is free. If tape is not in library, generally TSM will issue a request for the tape. David Longo [EMAIL PROTECTED] 05/17/02 10:25AM Hi Just want to verify AT my DISASTER REC.SITE we have a smaller lto library as compared to the one on our production site if its looking for a tape while restoring and not able to do so, does it wait till the tape is mounted before proceeding with the rest of the client restore? or does it skips restoring that file and moves on Pls let us know thanks in advance This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courriel est confidentiel et protege. L'expediteur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) designe(s) est interdite. Si vous recevez ce courriel par erreur, veuillez m'en aviser immediatement, par retour de courriel ou par un autre moyen. MMS health-first.org made the following annotations on 05/17/02 11:31:44 -- 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. ==
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 CompanyGlobal 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
Re: DISASTER Client Restores Slow
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 CompanyGlobal 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
Re: DISASTER Client Restores Slow
AS far as tsm is concerned , when there is no copy pool tape at the disaster recovery site at time of restore will result in request of mount tape until it is provided to that site! is this what I'm hearing? it will skip unless it is unavailable Thanks -Original Message- From: David Longo [SMTP:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 11:16 AM To: [EMAIL PROTECTED] Subject: Re: DISASTER Client Restores Slow It will wait for the tape. Normally that is. If there is a problem with the tape (access=unavailable for instance) it will skip it. If another client is currently restoring from this tape, it will wait till tape is free. If tape is not in library, generally TSM will issue a request for the tape. David Longo [EMAIL PROTECTED] 05/17/02 10:25AM Hi Just want to verify AT my DISASTER REC.SITE we have a smaller lto library as compared to the one on our production site if its looking for a tape while restoring and not able to do so, does it wait till the tape is mounted before proceeding with the rest of the client restore? or does it skips restoring that file and moves on Pls let us know thanks in advance This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courriel est confidentiel et protege. L'expediteur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) designe(s) est interdite. Si vous recevez ce courriel par erreur, veuillez m'en aviser immediatement, par retour de courriel ou par un autre moyen. MMS health-first.org made the following annotations on 05/17/02 11:31:44 -- 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. == This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courriel est confidentiel et protege. L'expediteur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) designe(s) est interdite. Si vous recevez ce courriel par erreur, veuillez m'en aviser immediatement, par retour de courriel ou par un autre moyen.
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 CompanyGlobal 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
Re: DISASTER Client Restores Slow
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
Re: DISASTER Client Restores Slow
Nikolai Sonin System Architect ESI Group 28381 Encina Drive Suite 100 Winters CA, 95694-9007 530-795-0200 ext. 235 Talafous, John G. [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 05/17/2002 07:33 AM Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: DISASTER Client Restores Slow You can use backup sets to create point in time restores of machines. Also with that few tape drives have you considered collocation. That way especially with LTO a small server and several incrementals will fit on one tape. Our CEO's PC is backed up using TSM with Collocation to an LTO drive and after a month of incrementals all his data sits on one tape. A test restore of his workstation took less than 3 hours. Also if you have over 100 servers you need to get more tape drives. 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 CompanyGlobal 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
Re: DISASTER Client Restores Slow
AT my DISASTER REC.SITE we have a smaller lto library as compared to the one on our production site if its looking for a tape while restoring and not able to do so, does it wait till the tape is mounted before proceeding with the rest of the client restore? or does it skips restoring that file and moves on If your tapes tapes are not checked in, but in state Read-Write or Read-Only, then the TSM server will issue a message requiring the checkin of a tape. Then you can safely checkout libvol a tape to make room in the library and checkin libvol the requested tape. There is a time limit: look at the Mount Wait time of the device class - default is 60 minutes. Only if the state of a tape is Unavailable or Offsite, the files will be skipped. Tschau Alex
Re: DISASTER Client Restores Slow
In North Carolina we've been advised that 7 miles is an 'adequate' distance for off-site storage for DR. And Wanda, be careful about how you view a 'hurricane zone'! Here in Chapel Hill, NC we're some 200 miles inland and got whomped by Hurricane Fran in '96. Power was out on campus for 3 days. I would think Md. might have similar susceptibility. But I am in total agreement, separate the TSM server and the tape library and eliminate so much physical tape movement. Prather, Wanda wrote: 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
