BackupPC-users

Re: [BackupPC-users] Using rsync for blockdevice-level synchronisation of BackupPC pools

2009-09-03 09:05:33
Subject: Re: [BackupPC-users] Using rsync for blockdevice-level synchronisation of BackupPC pools
From: Pieter Wuille <sipa AT users.sourceforge DOT net>
To: "General list for user discussion, questions and support" <backuppc-users AT lists.sourceforge DOT net>
Date: Thu, 3 Sep 2009 14:59:42 +0200
On Wed, Sep 02, 2009 at 01:08:27PM -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.

> > Keeping an LVM snapshot is a possibility, but it becomes somewhat complex to
> > manage: you get a snapshot of a volume containing a filesystem whose files
> > correspond to parts of a snapshot of a volume containing an (encrypted)
> > filesystem containing a directory that corresponds to a pool of backups...
> 
> The snapshot would just contain be the same files you had before the 
> last xfer started.   But, you'd still need space to hold the large file 
> changes.

It's definitely possible, and if your destination machine uses RAID5+, and
only relatively small changes per synchronisation run, it may be preferable
to keeping two sets on non-redundant storage.

> > 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.

-- 
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/

<Prev in Thread] Current Thread [Next in Thread>