[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Claus-Justus Heine
Subject: [rdiff-backup-users] State of the rdiff-backup project
Date: Thu, 13 Aug 2015 20:43:53 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0

Hash: SHA256

Hi there,

so this is not an email of some fancy package maintainer complaining
about a missing upstream-responsible.

So what is this? I'm using rdiff-backup -- successfully, including
critical restores -- for more than five years now, maybe much longer,
just don't remember any more.

There are some shortcomings, some missing distro support (why the heck
is using all of the Debian related world still V1.2.8? Hey)

One other point is the reason for this email:

- - the efficiency of rdiff-backup sometimes just sucks. No flames
intended. And first: oh well, efficiency. But hey: it does its job. Its
slow, but data safety is first place -- at least I never experienced any
data-lossage caused by a failing backup.

- - still, performance sucks: if a previous backup failed, then the
"regression" regularly takes ages (I am not talking about hours, but
several days for large backup sets)

- - if a remote directory is large, meaning has many entries, say some
multiple of 1e3, then backup speed sucks, especially, when the backup
set carries a large history record (i.e. one reaching back for half a
year or so)

AFAIK, these problems are not new. And so what. Still, a slightly
improved performance for the necessary "regression" after a failed
backup, or some slight speedup in the case of massively changed
backup-sets would really really be nice (actually: the regression case
is just the thing which really is a pain in the ass).

My question here: is there any work going on in this direction? I know
that there is no official "movement", but any hints about existing
trials, analysis, experience, work-arounds would be rellay appreciated.

OTHO, I just started to do some hacking. Did some "porting" to pypy,
which needed a rewrite of the cpython add-on module. Unfortunately, all
this is coincident with a larger hardware-update of my backup-server. So
thing are going on slowly. My current impression is that rdiff-backup
does an extremely bad job on directories with many entries and with a
large history. Maybe it calls readdir() just too often (and maybe some
associated sorting algorithm).

I do not volunteer as maintainer. But is there anyone's else experience
available, even some trials, partial insight, analyzed test-cases which
could shine some light on rdiff-backup obfuscated internals?

Some heretical last question: is there a real -- non-profit --
alternative, as featureful, as solid, heavily incremental? To my
knowledge: no. (once upon a time in the past, when Gentoo killed the
rdiff-backup, there were some comments from the Gentoo-maintainer, but
these somehow deemed me low featured).

Thanks (not least to the original authors of this nice "beast"), best,


- -- 
Claus-Justus Heine                      address@hidden

Version: GnuPG v2


reply via email to

[Prev in Thread] Current Thread [Next in Thread]