Gentoo masking rdiff-backup

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Gentoo masking rdiff-backup

Tobias Leupold
Hello list!

Gentoo Linux has masked rdiff-backup:

        Patrick Lauer <[hidden email]> (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.

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.

Tobias

_______________________________________________
rdiff-backup-users mailing list at [hidden email]
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Reply | Threaded
Open this post in threaded view
|

Re: Gentoo masking rdiff-backup

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

> Hello list!
>
> Gentoo Linux has masked rdiff-backup:
>
> Patrick Lauer <[hidden email]> (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


_______________________________________________
rdiff-backup-users mailing list at [hidden email]
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Reply | Threaded
Open this post in threaded view
|

Re: Gentoo masking rdiff-backup

Ian Zimmerman
On Mon, 14 Apr 2014 18:50:43 +0800
Patrick Lauer <[hidden email]> wrote:

Patrick> Dead upstream, has known dataloss bugs.  Please use
Patrick> something more sane: rsnapshot, backuppc, obnam, ...

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

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

Ok.  An important point though: do the "something saners" listed do
better _in those circumstances_ ?

--
Please *no* private copies of mailing list or newsgroup messages.

_______________________________________________
rdiff-backup-users mailing list at [hidden email]
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Reply | Threaded
Open this post in threaded view
|

Re: Gentoo masking rdiff-backup

Dominic Raferd-3
In reply to this post by Patrick Lauer

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 [hidden email] (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 [hidden email] (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 ;-)


_______________________________________________
rdiff-backup-users mailing list at [hidden email]
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Reply | Threaded
Open this post in threaded view
|

Re: Gentoo masking rdiff-backup

Jakob Unterwurzacher-2
In reply to this post by Ian Zimmerman
On Sa, Mai 17, 2014 at 6:27 , Ian Zimmerman <[hidden email]> wrote:
>
> Ok.  An important point though: do the "something saners" listed do
> better _in those circumstances_ ?

BackupPC handles disconnects just fine.

Jakob


_______________________________________________
rdiff-backup-users mailing list at [hidden email]
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki