rdiff-backup has been almost completely rewritten for v0.3.0, as it was for v0.1.0.
The main problem with versions 0.2.x was that the networking code was added to the not-remote-capable v0.1, and the result was unwieldy and prone to bugs when operating over a pipe.
There are some new features:
* Hopefully very few bugs, at least in basic file handling.
rdiff-backup has an extensive testing suite now, so it should be much more reliable.
* Complete support for reading and writing from and to files and directories that lack permissions, by temporarily changing them, and then changing them back later.
(See for instance the --change-source-perms switch.) As I found out there is a lot to this, so much that I'm not sure in retrospect I should have bothered.
:-)
* New more standard format for increment files.
See https://www.w3.org/TR/NOTE-datetime for the time standard.
The old format, besides being less standard, didn't take timezones into account.
* In the initial mirroring, rdiff-backup only copies the files that it needs to, so it is much quicker when you almost have an initial mirror already.
You can even the --mirror-only switch and make rdiff-backup into a slow version of rsync.
* Terminal and file verbosity levels can be selected separately.
So if you like a lot in your backup.log/restore.log but not much on your terminal, or vice-versa, you can set them at different numbers.
* New --test-server option so if something goes wrong you can see if it is because the server on the other side isn't being initialized properly.
* New --no-rdiff-copy option, which disables using rdiff to move files across a connection (it will still be used to make increment files however).
If the bottleneck is not bandwidth but local disks/CPUs, this options should speed things up.
There are, however, a few negatives:
* rdiff-backup now requires Python version 2.2 or later.
Sorry for the inconvenience but I use the new features a lot.
* It may be slightly slower overall than versions 0.2.x - the remote code is cleaner, but probably has higher overhead.
At least on my computer, rdiff-backup is still quicker than rsync for local mirroring of large files, but for remote mirroring, rsync will usually be much quicker, because it uses a fairly low-overhead pipelining protocol.
* Any old increments are incompatible because they use a different date/time standard.
If this is a big deal, try mailing me.
A converter shouldn't be very difficult to write, but I didn't want to take the time unless someone really wanted it.