[Top][All Lists]

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

Re: [rdiff-backup-users] Activity

From: mail
Subject: Re: [rdiff-backup-users] Activity
Date: Mon, 1 Aug 2011 11:14:03 +0200
User-agent: SquirrelMail/1.4.21


> Im wondering if there is anyone developing on rdiff-backup atm.

as for me, you are asking the crucial question concerning rdiff-backup.

There has not been a lot of development activity on rdiff-backup in the
recent times, and in addition, there are some fatal bugs in rdiff, causing
f*cked-up repositories especially when backuping to windows-hosted

Some time ago, I mailed the current maintainer, I guess it was Andrew
Ferguson, on the maintainance state of rdiff-backup -- however I got no

> Im asking because im
> thinking of using it in larger scale and want to know if there is some
> activity going on.

I also would like to use it in larger scale, as it is - to  the best of my
knowledge - the only free and flexible 4D-Backup-solution. However, I
experienced there are currently some caveats that I want to state here
(and propose some thoughts I had on what would make rdiff-backup more
  * The repository format. When recovering older files, rdiff-backup
really needs every single reverse delta, which is not only slow, but
also extremely fragile (if only one of those files is corrupted,
recovery will fail). A solution might be some additional,
larger-granularity reverse deltas that help speeding up recovery as well
as preserving integrity of "most of the timeline" even if some deltas
are corrupted.
  * Missing operators on an existing repository. For use of rdiff-backup
in larger scale it should be possible to e.g.
    - merge time steps
    - delete timesteps and correct deltas accordingly
    - remove subtrees (sometimes one backups large data sets by accident)
    - lots more.
  * Some bugs, especially on operating system independence. For example,
even though the issue was investigated sometime, it's still difficult to
use windows machines as target due to the "write only attribute on
folders" problem. Multiple users report mismatching hashes, and so on.
  * Maybe a dedicated network protocol would be nice (inspired by rsync),
but I think, this is less important.

Overall, am unsure whether it is more appropriate
  - to learn from the experience the great rdiffproject gave us and use
the base operators from rdiff-backup to maybe rewrite a whole new thing
with the above issues fixed (especially with a less fragile repository)
  - to continue fixing bugs on the small way in a project that seems
unmaintained (unfortunately, I lack the pro-grade python skills in order
to do it right).

I hope to start a discussion here on this thoughts, please contribute :)


reply via email to

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