I use this method to backup a remote datacenter in Asia   It works like
a champ.   The only drawback is that it requires extra diskspace at the
main location.   It even has an 'archive' option that will automatically
purge files at the main site when they are deleted at the remote site.

Using rsync over ssh is also an option if you do not have a VPN or private
WAN.

Regards,

Jon

On Mon, 25 Mar 2002, Richard Hellier wrote:

> Folks,
>       Can I throw in my ten cents' worth? What we do to backup smallish sites
> is to use the
> "rsync" software across a WAN (or VPN) link to send down each day's
> "deltas".  The initial sync
> takes some time, of course, but can be achieved by shipping disks
> (rather than tying up the link
> for a week ...).
> 
>       The savings are:
> 
> * No local admin staff needed to change tapes
> 
> * No library / tapes needed at remote site
> 
> * DR procedures are greatly simplified
> 
> * Restores can be speeded up since the required files are
>   "spinning" on your disks at the central site and so can be
>   turned around without needing tapes!
> 
> * Large economies of scale are possible by spending the itty-bitty
>   amounts from the remote sites on a humungous library (ies) at the
>   central site.
> 
> * A few staff can manage lots of sites once the framework is in place
> 
> Cheers,
> 
> Richard.
> 
> 
> 
> "Anderson, David" wrote:
> > 
> > Dan,
> > 
> > Here are my favorite options....your mileage may vary, check dealer for
> > details.....
> > 
> > 1.  Person at remote site changing tapes.  This is the most common and
> > cheapest, but sometimes (usually?!) unreliable.  Management loves this,
> > network/server administrators hate this one.  However it does provide a
> > GREAT scape-goat in the event of a real problem!
> > 
> > 2.  Operate some kind of tape library/changer using backup software at the
> > remote site yourself.  This will cost more but is controllable and
> > verifiable.  Have a user at the remote site change at "batch" of tapes at a
> > time.  In NetBackup parlance, this remote server would become a Media
> > Manager ($$$).
> > 
> > 3. Perform full backups on weekends and differential/incremental (some
> > variant of changed files) on weekdays using your current setup.  Netbackup
> > can help here with multistreaming.
> > 
> > 4.  Have management upgrade all remote sites to full ISDN, cable or DSL
> > speeds (yeah, like this would ever happen, right?!?!?)
> > 
> > David Anderson
> > Scripps Information Services
> > 
> > ------------------
> > 
> > Original Msg.....
> > 
> > Message: 9
> > From: "Sixbury, Dan" <Dan.Sixbury AT aquila DOT com>
> > To: "'veritas-bu AT mailman.eng.auburn DOT edu'"
> >          <veritas-bu AT mailman.eng.auburn DOT edu>
> > Cc: "Sixbury, Dan" <Dan.Sixbury AT aquila DOT com>
> > Date: Mon, 25 Mar 2002 13:11:41 -0600
> > Subject: [Veritas-bu] Backing up lots of small remote sites.
> > 
> > Has anyone architect a solution where they had lots of small servers in
> > field offices that had to be backed up, and the network bandwidth wasn't
> > sufficient to do network backups to a central office where the primary data
> > center was located?  This doesn't seem to have an easy answer/ solution.
> > These field sites have non-IT people and would make implementing local
> > backups difficult and unreliable.  i.e. Is the local guy changing the tape,
> > is he putting the right tape in, does he leave the tape on the kitchen
> > counter, etc.  The servers in each of the field sites are primarily NT or
> > 2000 servers.
> > 
> > Thanks,
> > Dan
> > 
> > _______________________________________________
> > Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu