Re: [rdiff-backup-users] State of the rdiff-backup project

[Dominic Raferd]

My 2p...

Rdiff-backup has limitations and it would be *really* good if someone 
who understood python could step up and maintain the code, but I don't 
see the problem with regressions. Yes they are slow but they should be 
emergency operations reserved for rare circumstances. If you are 
frequently experiencing broken backup session then I think you should 
look at why that is happening. We only use rdiff-backup within our lan 
and backups always complete. I have only needed regressions when we have 
inadventently backed up a lot of extraneous data, when I use them to 
overcome bloating of the repository. For offsite backup (of the entire 
set of repositories) we use rsync. I don't find backup speeds with 
rdiff-backup particularly slow BTW, but we run the backups at a quiet 
time when speed is not critical.

v1.2.8 is the official stable version, that's why Debian uses it. v1.3.3 
is officially 'unstable' although I haven't heard of any problems with 
it (and haven't used it).

I keep repositories on ext4 - I tried btrfs but found it very slow (on 
our vm) and the big wins that I sought (compression, deduplication) made 
it slower still - and btrfs deduplication is still buggy.

Dominic
http://www.timedicer.co.uk