Most of my remote sites are T1, but I do have 3 that are 256K lines.  I do
use client compression, but my remote clients are fairly newer hardware so
they can handle the extra load.  You will have to run some tests to see
what is faster, dependent on your particular hardware.  One thing to note
is that the remote site is pretty much unusable during the backup period
because of the combined network/client load.  If you're a 24x7 shop,
you'll probably have some unhappy users.

I did the initial backups during the weekend and things have been fine
except for a few glitches.  I have scheduled the cancel sessions command
to run in the morning just to ensure the lines are free for business
users.  I got bit by the daylight savings issue which caused basically a
full backup to run (last fall or spring?), so this is a safeguard for
issues like that.  Large changes, like ACL changes on NTFS volumes will
take a couple nights worth of backups to catch up again, but that is an
acceptable risk for the rare instances it does happen.

I used to run ADSM locally at these sites, but since I have upgraded to
TSM and centrally consolidated on one server.  Life is much easier now
with everything centralized.  As with most people, 99% of my restores are
small so they can be done over the 256K lines with no problems.  For the
larger and/or disaster restores, I have tested two options, but have yet
to actually use one of them in a live situation:

1.  Use backupsets.  The remote sites have local tape drives from the days
when they backed themselves up, so I have the same tape drive type at the
central site that I use to write backupsets for these clients.  The tape
can be shipped out and the restored locally using the client tape drive.
If you're using NTbackup now, they must have tape drives, hopefully they
are all the same type and you can get one at your main site to use for
backupsets.

2.  Restore to spare hardware locally and ship it as a replacement.  This
would probably be the option in a total disaster situation.

Just as a reference point, these are the average backup stats from my 256K
remote clients over the last 14 days (the second one is a little slower
hardware, the others are identical):
145MB backed up, 52 minutes elapsed time
45 MB backed up, 22 minutes elapsed time
71 MB backed up, 24 minutes elapsed time



===========================================
    John Monahan
    Network Team Coordinator
    Liberty Diversified Industries
    (763) 536-6677
===========================================





David Nash <daven AT GRAINSYSTEMS DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
04/04/01 10:50 AM
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Backup of Remote Sites


I have a question for all of the *SM/Network experts
out there.  We have a central office that we just
started using TSM at.  We also have several remote
offices that are connected to central office via
dedicated lines.  Theses sites currently are running
their own backups via NTBackup.  We are concerned that
these backups are unreliable/not offsite/not being done.
The dedicated lines are mostly 256Kbs lines but a few
are smaller.  Is it a good idea to try to back up these
sites across the WAN using *SM?  We realize that the first
backup would take a while, but after we suffer through that,
the amount of changed data would be small.  Is it a good
idea in this case to turn on client compression?  Any
suggestions would be appreciated.

Thanks,

--David Nash
  Systems Administrator
  Systems Administrator
  The GSI Group