-----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 hims...@claus-justus-heine.de 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----- _______________________________________________ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
