Re: [rdiff-backup-users] Gentoo masking rdiff-backup

[Dominic Raferd]

On 14/04/2014 11:50, Patrick Lauer wrote:

On 04/14/2014 04:41 PM, Tobias Leupold wrote:

Hello list!

Gentoo Linux has masked rdiff-backup:

	Patrick Lauer <address@hidden> (09 Apr 2014)
	Dead upstream, has known dataloss bugs.
	Please use something more sane: rsnapshot, backuppc, obnam, ...

I have been using rdiff-backup for years now on multiple machines, it has been 
always working fine for me and I really love it. Additionally, afaik there's 
no drop-in replacement doing basically the same thing atm.

Yes. But I've had two dataloss situations where rdiff-backup responds to
any error (e.g. network connection dropping, disc hiccup) by suiciding
with no good way to recover the backups.

And if there's any interruption sometimes it tries to re-fetch all data
from scratch (which can get a little bit sad with multi-TB data sets)
(Plus that exceeds the disk space I have allocated. Oops ...)

That's just a little bit too optimistic for my taste ;)

So what's the current state of the project? Is there any chance it will 
continue to be developed and come back to life? I do some Python programming 
myself, but I don't think my skills are sophisticated enough to fix rdiff-
backup bugs or even to maintain it.

Asking in another way: is there an rdiff-backup bugzilla listing those 
dataloss bugs? I would really want to see what _exactly_ is wrong with rdiff-
backup at the moment.

I did file at least one bug last year.

So far I haven't seen any activity on it, so that's not a good sign :\

Have fun,

Patrick

On 14/04/2014 11:50, Patrick Lauer wrote:

On 04/14/2014 04:41 PM, Tobias Leupold wrote:

Hello list!

Gentoo Linux has masked rdiff-backup:

	Patrick Lauer <address@hidden> (09 Apr 2014)
	Dead upstream, has known dataloss bugs.
	Please use something more sane: rsnapshot, backuppc, obnam, ...

I have been using rdiff-backup for years now on multiple machines, it has been 
always working fine for me and I really love it. Additionally, afaik there's 
no drop-in replacement doing basically the same thing atm.

Yes. But I've had two dataloss situations where rdiff-backup responds to
any error (e.g. network connection dropping, disc hiccup) by suiciding
with no good way to recover the backups.

And if there's any interruption sometimes it tries to re-fetch all data
from scratch (which can get a little bit sad with multi-TB data sets)
(Plus that exceeds the disk space I have allocated. Oops ...)

That's just a little bit too optimistic for my taste ;)

So what's the current state of the project? Is there any chance it will 
continue to be developed and come back to life? I do some Python programming 
myself, but I don't think my skills are sophisticated enough to fix rdiff-
backup bugs or even to maintain it.

Asking in another way: is there an rdiff-backup bugzilla listing those 
dataloss bugs? I would really want to see what _exactly_ is wrong with rdiff-
backup at the moment.

I did file at least one bug last year.

So far I haven't seen any activity on it, so that's not a good sign :\

Have fun,

Patrick

I agree with Tobias about rdiff-backup - I have been using it for over five years and I have found it to be very reliable and frankly pretty magical in what it achieves. I'm unaware of anything else that offers the same combination of efficient data transfer with efficient storage and reverse diffs/deltas. It has saved my bacon on several occasions.

It's true, and sad, that there is no formal coding activity on rdiff-backup and hasn't been for a while, although I have seen occasional unofficial patches. The best place to get info about bugs I think is this mailing list, always bearing in mind that people only post here when they have a problem.

If rdiff-backup is interrupted so that the archive is left in an inconsistent state then on the next run it should automatically 'regress' the archive back to its previous consistent state. (There is no official way to force this regression unless rdiff-backup considers that there has been an error, but there is an unofficial way.)

My strategy is to run rdiff-backup only over lan, and then use rsync with --link-dest for offsite backup (my timedicer-mirror program), and then only after successfully verifying the source archive. However it has been suggested that rdiff-backup can work reliably over the internet connection if you set ServerAliveInterval 5 in the client machine's /.ssh/config file; obviously this depends on any breaks in internet connectivity being short-term.

If your rdiff-backup repository is on a non-root LVM-based volume, you could try the following backup strategy which should be even safer:

• Create a read/write LVM snapshot of the volume holding your (consistent / good) rdiff-backup repository (discarding any pre-existing snapshot)
• Mount this snapshot and run rdiff-backup to the repository on the snapshot (not to the original repository location)
• If and only if rdiff-backup completes ok, use LVM's lvconvert --merge function to replace the original data with the snapshot data. After running this, unmount the original repository volume, deactivate, reactivate and remount it; you will then see the snapshot data at the original location and the physical merge of the data will continue in the background -see http://www.thegoldfish.org/2011/09/reverting-to-a-previous-snapshot-using-linux-lvm/
• Conversely, if rdiff-backup fails for any reason, you can happily discard the snapshot and even while it persists the original repository remains unaffected.
  
• The risk of rdiff-backup failure has been replaced by the risk of LVM merge failure, but as this activity is entirely local the risk should be low. For the very cautious, make/update a separate backup (e.g. with rsync) of the rdiff-backup repository onto a separate physical volume before starting the procedure above.
  

Dominic

TimeDicer: Free File Recovery from Whenever

P.S. As a test I have just recovered a database from rdiff-backup archive - the retrieved file is dated December 2008, since when it has been through 1724 updates. The file is perfect - though a little out-of-date ;-)