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

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

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


From: Claus-Justus Heine
Subject: Re: [rdiff-backup-users] State of the rdiff-backup project
Date: Fri, 14 Aug 2015 21:00:54 +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

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.

> 
> 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 ;)

> 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.

Many thanks for your feed-back,

Claus


- -- 
Claus-Justus Heine                      address@hidden

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

iQIcBAEBCAAGBQJVzjrkAAoJEF8rbXubOwvKlZIQALXxUAme+GPIMxxMGUThpMsg
P2EjSTCZeJXRWMHg3obGLWFg7eVf3L2NNuPd/i94rEyHTVQFNpXYC5+aTH3I9eKM
8GnapWqlZWF2ldfw4GLe8RGzm45e+WkeVF3MkiwIaMTQJ1jtOIF/kEtmeNgMWpeo
Mt8H/J3Rzk3Iz+zRbI+nUKRLq0ZQ9LDpiL+ob+IdnLSHSKT6LKiQz4o6VKHfimf6
EcfuaecD6J6HRoaPOTcepk73r3IgjFHMx5yYdGveav7TbloBiNJqycaxS3XXfNLf
I3QBJt0AqXJ4dnXSv77XrpnyysMCpDcLFQEwncU5q7iOBEB9gpeOWt5TGpteawXP
4W+Mw5hqnOK0f37EwwdKEVU6KUU87l/jOkMpO3uPYEjdX9ukykeLqwGq3gZakSry
0tGrzOvUuzXouIFW0bFNyBjQv1WBGHupzEm/R3sShoLe1Yn7G2viUt8dgLioNvAq
IvoD80q18bRElzWHfY1iHgno3lIkqIw4XKeEMw7SLydW74warYjBimVxnJ7Mf7jp
uafhW1hrqUVkKspWEmfLJ64wrEEJsecfTV7MGaJsybZ8zTg2OhS39H08gqPXQcc3
DxWmzyK+ZMSx3fV3puXT7IBQdBq280Sd/DxnLDmf0P05PM8A2zPheuvr/h/CpZma
88qGbv58T6MN2rNkKwKA
=0HCf
-----END PGP SIGNATURE-----



reply via email to

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