Re: [rdiff-backup-users] Activity

[D. Kriesel]

> Yes I think rdiff-backup is currently unmaintained. 
> Anyone who wants to take it forward (and has the skills to do so
> which unfortunately I have not) might need to make a fork 
> (which in due course could become rdiff-backup2?)
> [...]
> There was a discussion a while ago here and there was a 
> strong view that the existing project should be fixed rather than 
> a new one started, I suppose because rdiff-backup as it stands
> is 99.5% perfect and any project, even if it fixed the 0.5%,
> is likely to introduce new bugs and failings.

I second that. I believe that it might be the optimal solution to fork a
project like rdiffbackup2, but not only to "fix" the existing rdiff-backup,
but also to reform some architectural things (like the repository format,
and a few other things named).

>I don't see how creating larger-granularity reverse-deltas 
> would really make it more robust, 
>it would just make the archives bigger. 

Let us define the grade of robustness as the percentage of the backup
timeline a file is regressable to. Assume, one has got monthly reverse
deltas in addition to daily ones. Without the monthly deltas, one broken
daily delta makes a regression file for the complete backup timeline part
that is located earlier than the delta was created. With additional monthly
timelines, the corruption of some daily deltas just causes "gaps" in the
regressable timeline. Just to point out the principle, optimization needed
;). The archive would still be a lot smaller than a multi generation full
backup.  

However, maybe you are right and multigranularity reverse deltas are not the
way to do - still I see the problem of the "touchiness" of the backup
repository, with its lots and lots of single files that all need to be
correct without any file changed.

> >    * 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.
>
> yes these would be helpful especially to correct backup mistakes which can
permanently bloat a repository

And in cases where you want to thin out the time accuracy of earlier backups
(e.g. reducing the cover profile from ten year old data from daily to
monthly), and in lots and lots of other cases ... :-)

> Yes, the best advice re a windows target seems to be: don't. I think you
can reliably use rdiff-backup.exe to backup windows data to a linux target,
though.
Yep, both of your statements are true, in my opinion. However, the hash
mismatches are not only reported by windows users. I believe that the main
problem with windows targets is indeed the write only attribute on folders
that is used by windows in another way as developers are used to from unix
based systems. Especially, the write only attribute on folders is *not* used
in windows to prevent accidental altering of a folder (like you are used to
in files). It is used to mark a folder as "special" for the windows
explorer, like the font folder or similar, see "cause" in the link
http://support.microsoft.com/kb/326549/en-us. The write only attribute on
folders is therefore managed by the system itself (personally, I think this
way of marking special folders is complete bullshit).
 
> and I would add:
> ability to run a thorough verification of an rdiff-backup archive.
> add a switch to enable 'forced' regression of an archive. 

Agreed ;)

> AFAIK the only other open source project like rdiff-backup is duplicity. 

I would wish for rdiff-backup2 to stick with the reverse delta concept for
the reasons you mentioned.