I charged into rdiff-backup thinking it would be only a little more complex than rdiffdir was yesterday. Luckily I wasn’t too far off the mark.
rdiff-backup can make backups while conserving bandwidth, which is probably a great idea on the whole. It also makes incremental backups, and the home page promises file recovery over previous backups too.
I didn’t delve that far into it, but I do have a little to show for my effort:
My hope there was to show that rdiff-backup’s product is not only a mirror image of the source, but also includes data on what changed between runs. It might be a little difficult to follow; trust me if it’s not obvious.
Compared to a straight rsync, I can see where this would be preferable, if it conserves bandwidth and can offer access to past backups as well. I usually just refresh my archives with a simple
rsync -ah --progress --delete, and there have been times I wished I could step backward once or twice in history.
On the other hand, this is very clean and straightforward, without a lot of the wrangling that I’ve seen in some other console-based backup tools. Given the need — such as a large-scale networked system — I’d definitely think this over as an option. 😉
Nice short little post here. Though I will persuade you to stick with rsync – I did a comparison of rdiff-backup and rsync not too long ago, http://cookuop.co.uk/rsync-vs-rdiff-backup/. rdiff-backup is a hell lot more slower than rsync, however if you’re doing it locally to, say, an external hard drive then ignore my recommendation. But where a bottleneck is present, say, a network, the speeds are noticeably different.
Are you using rdiff-backup over a network? What are the speeds like? My server is RPi and rdiff-backup is CPU intensive moreso than what rsync is, so I’m curious to know what your experience is like with it.
Rsync can also be configured to give you file versioning, however this would require possible duplicate versions of your backups. The configuration wouldn’t be via the rsync utility itself, moreso with crontabs etc.
Thanks Adam. I probably will stick with rsync, just because it’s what I know and my backup needs are fairly small. Your analysis was interesting though — thanks for sharing. 😉