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
_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
