Tom, I guess what I am trying to say that if the connection is severed between the remote site and the main site TSM functions would cease as there was not a TSM server to tell the client what needed to be backed up(ie no access to TSM Database). If we were to place a 2nd TSM/VTL in the remote site and then TSM operations would continue to function and would cache on the VTL (provided there was space on the VTL) until the connection was restored. It this correct or would we still not need the second TSM/VTL as TSM functions would continue even if the connection to TSM was severed?
Thank You, Dan Lane [EMAIL PROTECTED] - Email "This email message and any attachments are confidential and may be privileged. If you are not the intended recipient, please notify the American Board of Family Medicine immediately -- by replying to this message or by sending an email to [EMAIL PROTECTED] If you are not the intended recipient, you must immediately destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you. For more information regarding the American Board of Family Medicine, please visit us at https://www.theabfm.org/."; -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Tom Wright Sent: Wednesday, September 26, 2007 11:07 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Archives across Wan Best practices Dan, As long as there was cache space available, the TSM server would complete backups to the local VTL and they would stay in cache until the line came back up again. Then they would transfer to the main site and onto physical tape. That is why it is good practice to size the cache for several day's worth of backups. A second TSM server is not required at the main site for this operation since the Tape Library appears to be local to TSM and the remote operation is handled from VTL-VTL-Physical Tape. That is, unless you would like to be able to restore the data onto a TSM server at the main site for DR purposes. That can be done by exporting the vTape from one virtual library into another one associated with the main site's TSM server, just like you would do in the real world. Tom -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Lane Sent: Wednesday, September 26, 2007 8:37 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Archives across Wan Best practices Tom, Thank you for the information. What if the line between the main site and the remote site went down? It would not complete the backup without a second TSM server correct? Thank You, Dan Lane [EMAIL PROTECTED] - Email "This email message and any attachments are confidential and may be privileged. If you are not the intended recipient, please notify the American Board of Family Medicine immediately -- by replying to this message or by sending an email to [EMAIL PROTECTED] If you are not the intended recipient, you must immediately destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you. For more information regarding the American Board of Family Medicine, please visit us at https://www.theabfm.org/."; -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Tom Wright Sent: Wednesday, September 26, 2007 8:48 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Archives across Wan Best practices Dan, Your basic concept of using a VTL is right on. The concept would be to use the VTL to get the data off of the SAN as fast as possible and free up the TSM server(s). I can't speak for other VTL's but the Gresham VTL uses disk as a cache so it stages the data onto disk and then would transfer the data across the WAN using one of its back-end interfaces (iSCSI, SCSI, or FC) to another VTL at the main site; which in turn would collect that data in cache and burst it onto physical tape. In using your example, the 6-day archive that the TSM server currently sees would probably occur in several hours or a day depending on the performance of the TSM server(s) since the Enterprise-class Gresham VTL can pull data off of the SAN at up to 5TB/Hr (Over 1TB/Hr/4Gb FC port) depending on block sizes. With the Gresham VTL the bottleneck has moved from the tape to the backup server since the VTL generally has a much higher performance capability than the backup server. It would then take the 6 days to trickle out of the VTL cache to the main site and onto physical tape but the TSM server would no longer be waiting for that to occur and would be free to perform the next backup. The disk cache in the local VTL would need to be sized properly so that there was always space for the next day's backup data in addition to the monthly archive data. The cache could also be sized to hold several days worth of backups that you determine is the most likely period for a potential restore. Even though the backup data is sent to physical tape ASAP, it will also remain in cache and is available for a potential restore until such time as the cache wraps around and needs that space for future data. This would mean the a likely restore would occur from the local cache rather than having to go to the main site to restore from physical tape. With this configuration there is no need for a second TSM server or for any TSM server-to-server functionality since the tape library appears to be local to TSM. I hope this helps. Tom Wright -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Lane Sent: Tuesday, September 25, 2007 10:33 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Archives across Wan Best practices Hello everyone, We have similar situation and questions... We also have a T1 line for doing Monthly Archival Full backups that take 6 full days to complete (line is completely saturated during this time), if all of the daily changes are not too large which shares this line also. The line is dedicated to TSM backups/restores. What I was thinking for speed of backups and being able to certify that every backup happens quickly and completely every night is to setup a second TSM server that would backup at that location to a virtual tape library then trickle those changes to the main site to tapes or to the san at that main site and then to tape. Is this possible or a valid solution? We are also running TSM 5.3.4 and all clients are current with 5.3.4. Possibility of adding more bandwidth i.e. T2 or greater is good. Which is better more bandwidth or a second TSM server? Can TSM servers work together to get backups done, kind of like a load balanced Backup? Thank You, Dan Lane [EMAIL PROTECTED] - Email "This email message and any attachments are confidential and may be privileged. If you are not the intended recipient, please notify the American Board of Family Medicine immediately -- by replying to this message or by sending an email to [EMAIL PROTECTED] If you are not the intended recipient, you must immediately destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you. For more information regarding the American Board of Family Medicine, please visit us at https://www.theabfm.org/."; -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Richard Sims Sent: Tuesday, September 25, 2007 9:56 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Archives across Wan Best practices On Sep 25, 2007, at 9:38 AM, Hayden, Mark wrote: > Hi All, just wanted to be pointed in the right direction to find > information on best practices on Archives across the T1 WAN? We are > having trouble finishing monthly archives on weekends running normal > Archives. I have tried to talk with upper management about getting rid > of Archives, but no go. We are running TSM 5.3.4 with older versions > of clients up to 5.3.4. Please advise Thanks Mark - Exactly what is trying to be achieved? It kinda sounds like they are trying to perform what amounts to a full backup over what was a high- speed link in 1962, based upon old-thinking full+incremental backups. TSM Incremental may supply what they actually need; otherwise, client compression would be the best they could probably do with the networking they have and approach they are trying to use. We could advise better if we had more information. Richard Sims
