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 >>> [EMAIL PROTECTED] 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:[EMAIL PROTECTED] On Behalf Of Shannon Bach Sent: Friday, August 27, 2004 3:06 PM To: [EMAIL PROTECTED] 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.