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 [email protected] List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
