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

[Robert Nichols]

On 08/13/2015 02:16 PM, Claus-Justus Heine wrote:
>  I'm really no python guy. But: I really
> would like to have the "regression takes ages" and "crowded directories
> take ages" being resolved. OR OR OR: would like to understand this
> issue. Cannot claim that I will be able to fix it. But I would very much
> like to understand what the heck is going on there. Just doesn't feel sa
> ne.

I doubt that the "regression takes ages" problem can be fixed within
rdiff-backup. It's inherently a complex operation that requires
searching throughout the archive for things that aren't consistent with
the previous state. Remember that you can't trust that the latest
metadata files are consistent with the current state of the mirror and
increments.  In large part it's due to use of the filesystem as a
database, with bits of information scattered in file names in the
increments directory and various metadata files. You're not going to
change that without a major rewrite.

I suppose one solution to the regression issue is to store the archive
in a filesystem or LVM volume that supports snapshots.  Rather than let
rdiff-backup do the regression, stop it and restore the snapshot. I
suspect the penalty in space (transient, until the snapshot is deleted)
and performance for the backup would be serious. And that still leaves
the issue of regressing more than the last level.

Like you, I'm no Python guy. Every time I try to study it, I end up as a
lump in a snake's belly. I think it's because there are some things
about the language that I hate (starting with the use of whitespace as a
syntax element) and the incompatibility of major versions. And then
there is the tendency of Python programmers to believe that stack
backtraces are an acceptable substitute for meaningful error messages.
It all leaves a bad taste that I just can't get around.

--
Bob Nichols     "NOSPAM" is really part of my email address.
                Do NOT delete it.