[Wolves] Tinkle tinkle little disk... (duplicity/crashplan/rdiff-backup)

David Goodwin david at codepoets.co.uk
Thu Jan 3 21:42:41 GMT 2008

Hash: SHA1


>>>> which I have a clear idea how to solve. They are:
>>>>  rsyncness
>>>>  encryption key loss
>>>>  bandwidth


> Not really, rsync divides the backup file into blocks,
> calculates checksums for each block then goes through
> the live file byte by byte looking for similar size
> blocks to avoid the problem of fixed sized blocks
> below.
> Yes I've read Tridges rsync paper :)
>> To be honest, it's probably better to do what Peter
>> suggested, and
>> break the files up into blocks, and encrypt each
>> block, then just ship
>> changed blocks. This does rely on a small change in
>> a large file not
>> having effects throughout the file, but that's
>> relatively unlikely.
> If you just ship changed blocks then you have a
> problem
> Take 123456789abc
> split it into three blocks 1234 5678 9abc and send
> them all to the backup machine
> delete the first character (the 1) then split it into
> blocks you get
> 2345 6789 abc


Random butt in from someone who's not really followed the thread :

1) rdiff-backup - like rsync, but keeps history around. I've been using
it for some time, it seems to work very well.

2) I've seen a derivative of rdiff-backup that uses gpg encryption. I
didn't get on with it too well, but it's definately "out" there, and
does work afaik. See http://www.nongnu.org/duplicity/

3) There was a backup product released last year which did a sort of
rsync-style ... : http://www.crashplan.com/features/features.vtl


- --
David Goodwin

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the Wolves mailing list