On Thu, Sep 03, 2009 at 11:35:50AM -0500, Les Mikesell wrote:
> Pieter Wuille wrote:
> > 
> >>> You're very right, and i thought about it too. Instead of using a RAID1 on
> >>> the offsite backup, there are two separate backups on the offsite machine,
> >>> and synchronisation switches between them. This also enables the use of
> >>> rsync's --inplace option.
> >> That should be safe enough, but doesn't that mean you xfer each set of 
> >> changes twice since the alternate would be older?
> > 
> > That's correct, but it hardly seems to matter. Due to a problem the offsite
> > machine was down once for over two weeks, and the subsequent synchronisation
> > run still only took 14h. The limiting factor is the sequential read speed of
> > the device, not the network.
> 
> Your network between sites must be exceptionally fast - that's probably 
> not a typical situation.

The network connection between them is indeed quite fast, but that doesn't
really matter. We're talking about a few gigabytes (maybe 10-20) of changes
that need to be transferred along with some checksums during a period of 14
hours. That's an average bandwidth of 3-4 megabit

> >>> Catting the part files together to a device after transmission isn't a
> >>> complete solution: what if the machine crashes during the catting...?
> >> The machine crash would have to destroy the filesystem containing the 
> >> chunks to be a real problem.  And then I wouldn't expect both your 
> >> primary server and the server holding the file chunks to die at the same 
> >> time, but it would mean you'd have to xfer the whole mess again. 
> >> Perhaps you could alternate the catting to 2 different devices so you'd 
> >> always have one ready to whisk off to the restore location.
> > 
> > Yes, i was wrong. A crash during the catting would normally not hurt the
> > files that already were transmitted. As long as you don't start transferring
> > the next set during the catting of the previous, there is no problem.
> 
> Maybe it doesn't matter if your network is as fast as your disks, but I 
> like the idea of ending up with a disk you can ship overnight or toss in 
> a briefcase and take to your disaster recovery location and start 
> restoring immediately.

That's a conforting thought. But it is maybe possible to add write support to
my script, and use that on the remote side. That way you would build a real
remote mirror device immediately, instead of a set of files that can be used to
reconstruct it. I'll try that one of the next days. Using that patched rsync
would allow you to do the same...

-- 
Pieter

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/