On Tue, Oct 21, 2014 at 12:30:58PM +0100, Laurie Brown wrote:
On 21/10/14 11:14, Chris Green wrote:
[SNIP]
That last point was my original one - the complexity of most backup systems seems to me to be such that it's often much simpler (and you get *exactly* what you want) to D-I-Y. This isn't a particular criticism of obnam, it was my starting point when I asked if the algorithm I posted some days ago looked correct.
[SNIP]
I'm not sure about the current level of support or development, but for many years we've been using rdiff-backup (www.nongnu.org/rdiff-backup). The most recent release was 2009, but it is stable and mature, and is, essentially, a front-end to rsync (well, it uses the python librsync library).
It was on my original shortlist a while back but I chose rsnapshot instead because rsnapshot does snapshots (i.e. each backup looks like a complete snapshot of everything you're backing up) whereas rdiff-backup does 'masters' plus diffs over a period.
This is a *big* distinction IMHO. With rdiff-backup you have to reconstruct any file you want to restore unless it happens to be unchanged since the last 'master' backup. Also as I understand how rdiff-backup works the diffs get more and more 'distant' as you make more and more backups.
With rsnapshot (or my more recent home-made system) hard links are used to save space where files haven't changed so every backup you make is a complete set of files, you can just copy the file back from the backup you select, no reconstruction needed.
I much prefer snapshots as they seem to me much safer and more robust.