I've also backed up sites on T1's or lower (some were 128kb/s). I just
spread the initial backup out over a couple/few days. The ones that
were still running in the morning, I just cancelled session on. The
next day it would mostly pick up where it left off, and it eventually
got done. This of course doesn't work so well if your daily change rate
doesn't allow the backups to finish on normal days. Luckily, ours did.
As Wanda said, restore is the bigger question. These sites are close
enough for us that we could restore a spare machine at the main site and
drive it out there. For anything less than large disaster, the link
speed didn't matter much. As a general rule, if the file(s) would take
more than 5/10min to restore over the link, I just waited until
afterhours to do it.
You also mentioned that 10MB service could be an option. I would push
for that if possible. We're in the middle of moving all our remote
sites to it, and if nothing else, it makes using the webgui on remote
servers much more palatable.
Troy Frank
Network Services
University of Wisconsin Medical Foundation
608.829.5384
>>> Wanda.Prather AT JHUAPL DOT EDU 8/27/2004 2:29:57 PM >>>
Depends on your RECOVERY REQUIREMENTS.
It usually works pretty well to backup small to medium file servers
over the
WAN. There are things you can do to minimize the amount of data backed
up
each night:
1) turn on COMPRESSION on the client end
2) implement TSM sub-file backup for those 2 clients
Who cares if it takes 48 hours or more to get the initial backup done,
if
you can do your daily incrementals in a couple of hours each night? It
is
just strictly a matter of computing bytes/hour capability of your WAN
connection vs. the bytes/day to be backed up from the 2 clients.
NOW THE PROBLEM: What are your requirements for RESTORE?
THAT is where it gets tricky.
If your remote sites only expect to do restores of a few files at a
time,
fine.
If you are talking BIG DATA BASES on those file servers, what are the
time
constraints?!?
If you have a critical app on those servers, backup/restore over the
WAN may
not be the best approach.
If it's just an ordinary file server that people could stand to have
down
for a while, it may be a good solution.
If the data has a low change rate so that backups work OK, but there is
so
MUCH data on the server it would take days to restore completely, here
is
another possibility:
Backup over the WAN
Keep a spare server machine in the primrary data center
In case of disaster at the remote site, recover the data to the spare
over
the (fast) local network
FED-EX the MACHINE to the remote site!
Lots of ways to address the problem if you plan ahead...
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
Of
Shannon Bach
Sent: Friday, August 27, 2004 3:06 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Question on a new network link proposed
There's some new construction going on in a remote site which will
have
their own Data Center(they will not be able to use our LAN because of
some
of the applications running). They want their servers to be backed-up
by my
TSM Server but because of the network configuration proposed, I have
questions if this would be feasible. I'm hoping some of you Guru's can
shed
some light and give me some food for thought.
There will be two Client Servers that will need to be backed-up, they
will
most likely be Win2000's, but I'm still waiting for confirmation on
that.
The current network link proposed is a WAN with a 1.5 meg T1.
I believe this would be way too slow to even be worth while but they
want to
send the backups through this Data Center
i stead of having a stand alone backup. We currently have an MVS/OS390
5.1.7 TSM Server, with plans to go to 5.2 for Z-OS by October. The
Network
person in charge thinks he could request 10 megs for the T1, but how
much
would this help for band width and speed?
Any help or ideas will be much appreciated.
Thanks!
Shannon Bach
Operations Analyst
IMS Data Center Services
Madison Gas & Electric Co.
Office 608-252-7260
Confidentiality Notice follows:
The information in this message (and the documents attached to it, if any)
is confidential and may be legally privileged. It is intended solely for
the addressee. Access to this message by anyone else is unauthorized. If
you are not the intended recipient, any disclosure, copying, distribution
or any action taken, or omitted to be taken in reliance on it is
prohibited and may be unlawful. If you have received this message in
error, please delete all electronic copies of this message (and the
documents attached to it, if any), destroy any hard copies you may have
created and notify me immediately by replying to this email. Thank you.
|
