ADSM-L

Re: [ADSM-L] Archives across Wan Best practices

2007-09-26 09:39:36
Subject: Re: [ADSM-L] Archives across Wan Best practices
From: Daniel Lane <dlane AT THEABFM DOT ORG>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 26 Sep 2007 09:37:16 -0400
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
dlane AT theabfm DOT org - 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 dlane AT theabfm DOT org. 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:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Tom Wright
Sent: Wednesday, September 26, 2007 8:48 AM
To: ADSM-L AT VM.MARIST DOT 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:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Daniel Lane
Sent: Tuesday, September 25, 2007 10:33 AM
To: ADSM-L AT VM.MARIST DOT 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
dlane AT theabfm DOT org - 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 dlane AT theabfm DOT org. 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:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Richard Sims
Sent: Tuesday, September 25, 2007 9:56 AM
To: ADSM-L AT VM.MARIST DOT 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