Re: TSM DR restore query
Neil, In my opinion that TSM server is having disk contention problems. At one customer, running TSM on Windows 2003 server, they perform regular DR test restores of their TSM DB (approximately 45GB, 52% of 80GB total DB volumes), and it finishes in less than 1.5 hours. However, this is in their test environment with their DB and Logs on separate SAN LUNs, if they test the DR on a less capable Windows server (with limited internal disk drives) it takes a lot longer. BTW, I did implement your suggestion. Basically, the production TSM server used SAN for the first copy of the DB and Log volumes, and we used TSM mirror copies on a separate SAN (approximately 2 miles away). We did develop a DR strategy to "recover" the TSM DB from that mirrored copy, and successfully tested that strategy multiple times. We eventually stepped away from that strategy because of potential support issues. Possible support issues were a black cloud when discussing DR procedures with the backup clients. Regards, Brian Matthias Storage Engineer Datalink Corporation [EMAIL PROTECTED] www.datalink.com -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Neil Sharp Sent: Monday, February 04, 2008 10:28 To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM DR restore query Hello I was wondering if anybody could help or advise with the following question. I need to devise a solution to speed up DR for one of my customers. Currently their DR solution is the classic restore from TSM DB tape and then load all of the off site tapes into the DR library and then perform the client restores. The problem is that the TSM DB restore can take in the region of 5 hours. The TSM DB is 45GB. I was thinking of using the following method. Can any one see any issues with this? *On the primary TSM server:* They have a Windows 2003 Standard Edition TSM server. I am proposing that we set up TSM DB and log mirroring, one copy on local disk and the second copy on SAN attached disk. *On the DR site:* They also have a TSM 2003 Standard Edition TSM server. When DR is to be tested / invoked, I would propose that they re-zone the DR TSM server to access the LUN that contains the DB and logs. Ensure that the DR TSM server's dsmserv.dsk points to the mapped drives. Note the the TSM tape library is also SAN attached. Any comments / experiences would be appreciated.
Re: TSM DR restore query
>> On Mon, 4 Feb 2008 17:32:26 +, Neil Sharp <[EMAIL PROTECTED]> said: > The majority of the restore time is spent in formatting the DB and logs. > They are actually restoring from a fileclass backup of the TSM DB. I know > when they told me these times I found them hard to believe as well. So run some automated process at the DR site which evaluates the DB Volume status and re-run the format when it no longer matches. Then when the balloon goes up, you've already got a formatted volume. EricEricEricEricEricEricEricEricEricEricEricEricEricEricEricEricEricEric :) - Allen S. Rout
Re: TSM DR restore query
On Feb 4, 2008, at 12:32 PM, Neil Sharp wrote: Thanks Charles for responding The majority of the restore time is spent in formatting the DB and logs. ... This gets back to the site decisions made as to the platform choice for the TSM server, when management makes an informed choice as to which to buy based upon all factors. A platform which allows the use of raw logical volumes, such as AIX, completely eliminates the need for such formatting and allows disaster recovery to be immediately initiated. This can make an immense difference to a business's recover time. We as technicians have to live with the choices made by others, but at a minimum we can point out the consequences of a given platform choice. Richard Sims
Re: TSM DR restore query
-David Longo wrote: - >The majority of the restore time is spent in formatting the DB and >logs. They are actually restoring from a fileclass backup of the >TSM DB. I know when they told me these times I found them hard to >believe as well. Our DR plan is similar to the one described in earlier postings. We have been able to shorten the process significantly by running dsmfmt processes in parallel. At our last DR test we started all 35 dsmfmt commands at the same time, each responsible for a file a little over 2 GB in size. The processes finished in rapid succession about 15 minutes later. This was on a mainframe Linux system.
Re: TSM DR restore query
Have you thought of splitting out into Two or more TSM Servers to reduce DB sizes? It may not be possible, but it might help. See Ya' Howard -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Neil Sharp Sent: Monday, February 04, 2008 11:32 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM DR restore query Thanks Charles for responding The majority of the restore time is spent in formatting the DB and logs. They are actually restoring from a fileclass backup of the TSM DB. I know when they told me these times I found them hard to believe as well. On 04/02/2008, Hart, Charles A <[EMAIL PROTECTED]> wrote: > > I think the first question id 45GB restored in 5Hours, that's 5 GB > hour / 1.3MBS Second... What kind of Tape Drive are you using, is it > on its own HBA (Don't Mix Disk / Tape I/O down same path) > > Sounds like you have an I/O challenge. As far as the Idea below, > never tried, but take in consideration that if the TSM DR box is in a > different geographical location you'll have to use FCIP or Disk Frame > replication to gain access to those volumes. > > -Original Message- > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf > Of Neil Sharp > Sent: Monday, February 04, 2008 10:28 AM > To: ADSM-L@VM.MARIST.EDU > Subject: [ADSM-L] TSM DR restore query > > Hello I was wondering if anybody could help or advise with the > following question. > > I need to devise a solution to speed up DR for one of my customers. > Currently their DR solution is the classic restore from TSM DB tape > and then load all of the off site tapes into the DR library and then > perform the client restores. The problem is that the TSM DB restore > can take in the region of 5 hours. The TSM DB is 45GB. > > I was thinking of using the following method. Can any one see any > issues with this? > > *On the primary TSM server:* > > They have a Windows 2003 Standard Edition TSM server. I am proposing > that we set up TSM DB and log mirroring, one copy on local disk and > the second copy on SAN attached disk. > > *On the DR site:* > > They also have a TSM 2003 Standard Edition TSM server. When DR is to > be tested / invoked, I would propose that they re-zone the DR TSM > server to access the LUN that contains the DB and logs. Ensure that > the DR TSM server's dsmserv.dsk points to the mapped drives. > > Note the the TSM tape library is also SAN attached. > > Any comments / experiences would be appreciated. > > > This e-mail, including attachments, may include confidential and/or > proprietary information, and may be used only by the person or entity > to which it is addressed. If the reader of this e-mail is not the > intended recipient or his or her authorized agent, the reader is > hereby notified that any dissemination, distribution or copying of > this e-mail is prohibited. If you have received this e-mail in error, > please notify the sender by replying to this message and delete this e-mail immediately. >
Re: TSM DR restore query
You said is a W2003 server. What are the details of it? CPU, memory, etc. Maybe that is problem? Or is their restore time including not just the DB restore, but all the "prep" work, etc. involved in the restore? DL >>> Neil Sharp <[EMAIL PROTECTED]> 2/4/2008 12:32 PM >>> Thanks Charles for responding The majority of the restore time is spent in formatting the DB and logs. They are actually restoring from a fileclass backup of the TSM DB. I know when they told me these times I found them hard to believe as well. On 04/02/2008, Hart, Charles A <[EMAIL PROTECTED]> wrote: > > I think the first question id 45GB restored in 5Hours, that's 5 GB hour > / 1.3MBS Second... What kind of Tape Drive are you using, is it on its > own HBA (Don't Mix Disk / Tape I/O down same path) > > Sounds like you have an I/O challenge. As far as the Idea below, never > tried, but take in consideration that if the TSM DR box is in a > different geographical location you'll have to use FCIP or Disk Frame > replication to gain access to those volumes. > > -Original Message- > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of > Neil Sharp > Sent: Monday, February 04, 2008 10:28 AM > To: ADSM-L@VM.MARIST.EDU > Subject: [ADSM-L] TSM DR restore query > > Hello I was wondering if anybody could help or advise with the following > question. > > I need to devise a solution to speed up DR for one of my customers. > Currently their DR solution is the classic restore from TSM DB tape and > then load all of the off site tapes into the DR library and then perform > the client restores. The problem is that the TSM DB restore can take in > the region of 5 hours. The TSM DB is 45GB. > > I was thinking of using the following method. Can any one see any issues > with this? > > *On the primary TSM server:* > > They have a Windows 2003 Standard Edition TSM server. I am proposing > that we set up TSM DB and log mirroring, one copy on local disk and the > second copy on SAN attached disk. > > *On the DR site:* > > They also have a TSM 2003 Standard Edition TSM server. When DR is to be > tested / invoked, I would propose that they re-zone the DR TSM server to > access the LUN that contains the DB and logs. Ensure that the DR TSM > server's dsmserv.dsk points to the mapped drives. > > Note the the TSM tape library is also SAN attached. > > Any comments / experiences would be appreciated. > > > This e-mail, including attachments, may include confidential and/or > proprietary information, and may be used only by the person or entity to > which it is addressed. If the reader of this e-mail is not the intended > recipient or his or her authorized agent, the reader is hereby notified > that any dissemination, distribution or copying of this e-mail is > prohibited. If you have received this e-mail in error, please notify the > sender by replying to this message and delete this e-mail immediately. > # 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: TSM DR restore query
Thanks Charles for responding The majority of the restore time is spent in formatting the DB and logs. They are actually restoring from a fileclass backup of the TSM DB. I know when they told me these times I found them hard to believe as well. On 04/02/2008, Hart, Charles A <[EMAIL PROTECTED]> wrote: > > I think the first question id 45GB restored in 5Hours, that's 5 GB hour > / 1.3MBS Second... What kind of Tape Drive are you using, is it on its > own HBA (Don't Mix Disk / Tape I/O down same path) > > Sounds like you have an I/O challenge. As far as the Idea below, never > tried, but take in consideration that if the TSM DR box is in a > different geographical location you'll have to use FCIP or Disk Frame > replication to gain access to those volumes. > > -Original Message- > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of > Neil Sharp > Sent: Monday, February 04, 2008 10:28 AM > To: ADSM-L@VM.MARIST.EDU > Subject: [ADSM-L] TSM DR restore query > > Hello I was wondering if anybody could help or advise with the following > question. > > I need to devise a solution to speed up DR for one of my customers. > Currently their DR solution is the classic restore from TSM DB tape and > then load all of the off site tapes into the DR library and then perform > the client restores. The problem is that the TSM DB restore can take in > the region of 5 hours. The TSM DB is 45GB. > > I was thinking of using the following method. Can any one see any issues > with this? > > *On the primary TSM server:* > > They have a Windows 2003 Standard Edition TSM server. I am proposing > that we set up TSM DB and log mirroring, one copy on local disk and the > second copy on SAN attached disk. > > *On the DR site:* > > They also have a TSM 2003 Standard Edition TSM server. When DR is to be > tested / invoked, I would propose that they re-zone the DR TSM server to > access the LUN that contains the DB and logs. Ensure that the DR TSM > server's dsmserv.dsk points to the mapped drives. > > Note the the TSM tape library is also SAN attached. > > Any comments / experiences would be appreciated. > > > This e-mail, including attachments, may include confidential and/or > proprietary information, and may be used only by the person or entity to > which it is addressed. If the reader of this e-mail is not the intended > recipient or his or her authorized agent, the reader is hereby notified > that any dissemination, distribution or copying of this e-mail is > prohibited. If you have received this e-mail in error, please notify the > sender by replying to this message and delete this e-mail immediately. >
Fw: TSM DR restore query
Neil, You'll want to read through this document: http://www-1.ibm.com/support/docview.wss?rs=663&context=SSGSG7&q1=replication&uid=swg21205074&loc=en_US&cs=utf-8&lang=en There's a lot of things to think about with what you're looking at doing, and it covers things well. Nick Cassimatis - Forwarded by Nicholas Cassimatis/Raleigh/IBM on 02/04/2008 12:03 PM - "ADSM: Dist Stor Manager" wrote on 02/04/2008 11:28:05 AM: > Hello I was wondering if anybody could help or advise with the following > question. > > I need to devise a solution to speed up DR for one of my customers. > Currently their DR solution is the classic restore from TSM DB tape and then > load all of the off site tapes into the DR library and then perform the > client restores. The problem is that the TSM DB restore can take in the > region of 5 hours. The TSM DB is 45GB. > > I was thinking of using the following method. Can any one see any issues > with this? > > *On the primary TSM server:* > > They have a Windows 2003 Standard Edition TSM server. I am proposing that we > set up TSM DB and log mirroring, one copy on local disk and the second copy > on SAN attached disk. > > *On the DR site:* > > They also have a TSM 2003 Standard Edition TSM server. When DR is to be > tested / invoked, I would propose that they re-zone the DR TSM server to > access the LUN that contains the DB and logs. Ensure that the DR TSM > server's dsmserv.dsk points to the mapped drives. > > Note the the TSM tape library is also SAN attached. > > Any comments / experiences would be appreciated.
Re: TSM DR restore query
I think the first question id 45GB restored in 5Hours, that's 5 GB hour / 1.3MBS Second... What kind of Tape Drive are you using, is it on its own HBA (Don't Mix Disk / Tape I/O down same path) Sounds like you have an I/O challenge. As far as the Idea below, never tried, but take in consideration that if the TSM DR box is in a different geographical location you'll have to use FCIP or Disk Frame replication to gain access to those volumes. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Neil Sharp Sent: Monday, February 04, 2008 10:28 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM DR restore query Hello I was wondering if anybody could help or advise with the following question. I need to devise a solution to speed up DR for one of my customers. Currently their DR solution is the classic restore from TSM DB tape and then load all of the off site tapes into the DR library and then perform the client restores. The problem is that the TSM DB restore can take in the region of 5 hours. The TSM DB is 45GB. I was thinking of using the following method. Can any one see any issues with this? *On the primary TSM server:* They have a Windows 2003 Standard Edition TSM server. I am proposing that we set up TSM DB and log mirroring, one copy on local disk and the second copy on SAN attached disk. *On the DR site:* They also have a TSM 2003 Standard Edition TSM server. When DR is to be tested / invoked, I would propose that they re-zone the DR TSM server to access the LUN that contains the DB and logs. Ensure that the DR TSM server's dsmserv.dsk points to the mapped drives. Note the the TSM tape library is also SAN attached. Any comments / experiences would be appreciated. This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately.
TSM DR restore query
Hello I was wondering if anybody could help or advise with the following question. I need to devise a solution to speed up DR for one of my customers. Currently their DR solution is the classic restore from TSM DB tape and then load all of the off site tapes into the DR library and then perform the client restores. The problem is that the TSM DB restore can take in the region of 5 hours. The TSM DB is 45GB. I was thinking of using the following method. Can any one see any issues with this? *On the primary TSM server:* They have a Windows 2003 Standard Edition TSM server. I am proposing that we set up TSM DB and log mirroring, one copy on local disk and the second copy on SAN attached disk. *On the DR site:* They also have a TSM 2003 Standard Edition TSM server. When DR is to be tested / invoked, I would propose that they re-zone the DR TSM server to access the LUN that contains the DB and logs. Ensure that the DR TSM server's dsmserv.dsk points to the mapped drives. Note the the TSM tape library is also SAN attached. Any comments / experiences would be appreciated.
