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

[Frank Crawford]

On Fri, 2015-08-14 at 21:00 +0200, Claus-Justus Heine wrote:
> Am 14.08.2015 um 20:53 schrieb Dominic Raferd:
> > 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 
> > ha
> ve
> > 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.
> 
> Well, I'am actually in progress of figuring things out on my side.
> However, I experience slowness at times. Also: even if regressions 
> are
> extra-ordinary events, it still does not feel right that they take so
> long. At least I want to try to understand what is going on there.

As said elsewhere, the slow regression may be due to the I/O that rdiff
has to go through.

A different but related issue I just hit was a massive change to
metatdata on all the files (reset selinux contexts across the system)
caused the backup time to go from around 1 hour to over 10 hours, and
no indication of what was the problem.  The actual backup size wasn't
much, but having to read and compare all the metadata just sucked, and
it wasn't until later I realised why.  Of course it was also a once-off
issue.

> > 
> > 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).
> 
> Silly me. You are right. Maybe I should volunteer as maintainer and 
> as
> first act copy v1.3.3 tp v1.4.0 and declare it stable ;)

That would be good, but also to get all the patches that various
distributions, etc, have also applied would help.  I'm pretty sure that
the recent one to handle the upgrade to librsync isn't in the official
repo, but everyone needs it to work.

Also, given the slow pace of change, python3 will come around to bite
us soon enough.  It may be a few years before leading distributions
drop python2 entirely, but it will happen and then rdiff-backup has to
either adapt or be dropped.

> > 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) 
> > ma
> de
> > it slower still - and btrfs deduplication is still buggy.
> 
> For my "slowness" experience this may very well be the problem, at 
> the
> moment I'm running btrfs. However, as I'm right now replacing the 
> backup
> hardware this would be the time to change something. We will see.

Even these sort of comments need to be tracked, so people realise that
it isn't always rdiff-backup that is the issue.  The underlying system
can have big effects.

> Many thanks for your feed-back,
> 
> Claus

Regards
Frank
> 
> _______________________________________________
> rdiff-backup-users mailing list at address@hidden
> https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
> Wiki URL: 
> http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
>

signature.asc
Description: This is a digitally signed message part