[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dominic Raferd
Subject: Re: [rdiff-backup-users] State of the rdiff-backup project
Date: Fri, 14 Aug 2015 19:53:42 +0100
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]