It works as follows:
- Let say you already have file that is older version, or perhaps corrupted, you use rdiff to generate its signature
- you go then to the place which contains proper file and use the signature file to generate a patch file
- then you use the patch file to fix your local file
There is an elegant simplicity to rdiff, IMHO.
rdiff-backup backs up one directory to another, possibly over a network. The target directory ends up a copy of the source directory, but extra reverse diffs are stored in a special subdirectory of that target directory, so you can still recover files lost some time ago. The idea is to combine the best features of a mirror and an incremental backup. rdiff-backup also preserves subdirectories, hard links, dev files, permissions, uid/gid ownership (if it is running as root), and modification times. Finally, rdiff-backup can operate in a bandwidth efficient manner over a pipe, like rsync. Thus you can use rdiff-backup and ssh to securely back a hard drive up to a remote location, and only the differences will be transmitted.
Unfortunately, it seems not to be developed any longer, and it has a few things that would need ironing out:
* You can't pause a backup and continue later. * Some operations (notably recovery after an aborted backup run) is excruciatingly slow. It takes tens of hours for me with a backup of 40 GB or so (on a low-powered computer as server, though). I think rdiff-backup-fs is resource hungry as well, which is perhaps partly understandable, since it has to go through a series of reverse diffs to present old versions of a file. * I tried it on Windows once, and it could apparently not handle paths longer than a few hundred characters (due to using that older Windows API, whatever it's called). * You can't delete intermediate backups, only the oldest one.