rdiff-backup-users
[Top][All Lists]
Advanced

[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

-----BEGIN PGP SIGNED MESSAGE-----
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

- -- 
Claus-Justus Heine                      address@hidden

http://www.claus-justus-heine.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVzOVmAAoJEF8rbXubOwvKv/UP/i8gGpHTGFfP15sMjIPBb5Gm
Qx+BwGQzVib2Tqi6gYDoAZKeaTuG5McEEynXZB7m8UvKybFFOTrHckz1R+K5dUwz
I9HBZ7IJ4gMkYO8w7RcE7MnYZmotBxDji0G7tNtQlbBTloxQ+JxAC56cRQHtrEQi
/eWDinnqUBQCJmtyi4DMWAcVNBSyJ8mc5vYIl7svUMksjhLBkDjA9NpTIFcQPzzw
eTg7RtyhY8tV6tBb9YeailKe1BwYiEQG2AKIGe7uixHpbuousgvNaBqX61mvi6Y4
MbNJf0pUDMe4W6u4O49kWbbeT1wu8DSYWbC3mE5CHXBiOHrlu0/B0jLWmE6p5ebw
0XRrfBb8SYqA2Qd0ZVZhlARhVQn7+nrcUKbDI4HdqCN2HAMovB6awujGKO9Uc6HU
Qq47rDFtxRKa0JyRxdw+W1XH1iPXCX4Zgt9BiHssS4y4wVrWGl3yh3lHpF+VZR6k
PUR4qrYf62hfSAK1dZvAkhhX9gumqCKq9tmeIyiOSkJiJbg1D+yOawIoTrTXiVhZ
65sMlMphx3RzpjE39hhfLdupZvngqdNbchXBMZf2t7uUaUGTtLIOx+oZVIZrdtVw
Thdl71bUYxzG+ujFk1w54jPQqrxntMrG+kcVNLdlEewaciXO6GAeYqEKs/ZMGpXj
hEwaeNS67Prq291Vbs/t
=ddOk
-----END PGP SIGNATURE-----



reply via email to

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