I have been using rdiff-backup for about 4 1/2 years and have found
it very stable and reliable. I created and maintain a Windows
wrapper for rdiff-backup called TimeDicer
http://www.timedicer.co.uk/index and of course use it (and therefore
rdiff-backup) every day.
There are two versions of rdiff-backup in common use: 1.2.8 is the
'stable' version (which I use), 1.3.3 is 'unstable' but is actually
stable too by all accounts. No significant difference in
functionality I think.
I have repositories (archives) going back 4 1/2 years and can
retrieve versions of files that have since changed and been backed
up daily going back to the beginning of that time. Although I have
never needed to do that, I have on several occasions needed to
recover files from the past (i.e. earlier than the most recent
backup) and rdiff-backup has delivered the goods and been a
life-saver (OK not quite literally).
I wrote a page about backup technologies when I was - as you now are
- researching them, and it might help you - here: http://www.timedicer.co.uk/finding_a_backup_solution
Weaknesses of rdiff-backup?
- It was not designed with security in mind - indeed the most
recent backup is stored 'in the clear' - a related tool
'duplicity' (which however uses forward deltas instead of
reverse deltas) addresses this if you need it.
- Some reports of problems when backing up *to* a Windows file
system destination, and there are some unconfirmed problems with
storing Windows ACLs; however I have found it totally reliable
for non-ACL Windows file backup to Linux machine/file system
(and recovery therefrom).
- It lacks a really robust and usable verification system (it
does allow verification but I understand it does not do a 100%
job, which is a bit of an oxymoron) - however my experience is
that it backup repositories are reliable nevertheless. For
TimeDicer I wrote a script
which can do 100% verification (by repeated runs of rdiff-backup
- Not great over unstable connections (e.g. internet) - it works
but is not recommended (repeated failures might lead to
repository corruption). I always run rdiff-backup to a
destination on our local LAN (via TimeDicer) and then use rsync
to backup the repositories offsite (via timedicer-mirror
- Although you can remove 'old history' for all files in a
repository (e.g. all backups older than six months, say), there
is no easy way to remove specific files or directories from a
backup repository without removing the whole repository. Because
all previous history is retained, if you inadvertently backup a
source which contains data you don't want to keep (and might
bloat the backup), it is no good just correcting the backup for
next time, because rdiff-backup will keep the unwanted files in
its 'history'. Workaround is to regress the whole repository
back to the time before the mistake occurred (losing all
subsequent changes) and then resume backups with the
now-corrected source specification. I wrote a script
which can help with this.
- No maintainer - fixed! Thanks Ned!
In summary, rdiff-backup is not outdated and remains a fantastic
and practical tool - and it is free and open-source.
On 13/05/13 21:41, Ans Alghamdi wrote:
I just find it a bit odd that this powerful tool does not
have any bug fix (if there are any) since 2009!
So is it outdated, or its so powerful that there is no need
for any update?
I've already posted this quastion on serverfault at:
(P.S. The reason behind this is that I'm looking for a backup
tool. rdiff-backup really suits my needs but the lack of bug
fixes/active development is what is keeping me away)
rdiff-backup-users mailing list at address@hidden
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki