Re: Problems with backup after using rdiff-backup-delete.py

[Patrik Dufresne]

Hi Robert Nichols,

Your contribution is welcome. There is a folder with user's contribution in
rdiff-backup repositories. We could probably leave it their with some user
warning. So either submit a Pull Request in github or send it here as
attachment and will submit it for you.

https://github.com/rdiff-backup/rdiff-backup/tree/master/tools/misc


On Fri, Nov 29, 2019 at 1:54 PM Robert Nichols <address@hidden>
wrote:

> On 11/29/19 11:00 AM, Brian Gupta wrote:
> > So I work with OP, and am trying to sort out our path forward.
> >
> > We have been using rdiff-backup for over 7 years, and we generally
> > keep backups indefinitely. A few years ago or so, we had to remove
> > certain PII data from our backups, for contractual reasons. The
> > ability to do these selective deletions is now an ongoing requirement.
> >
> > We contracted with rdiff-backup's primary maintainer at the time,
> > sol1, to add this functionality for us, and they offered to write it
> > as an open source contribution, as they said it was a very common
> > request. When they did this work for us, there was no indication that
> > it wouldn't be production ready. (We paid extra for a thorough
> > validation.)
> >
> > This is something I understand has now changed, as they are no longer
> > the primary maintainer and are disparaging the tool on a public
> > mailing list. [1] No bad blood here, we understand that open source is
> > hard, and companies' priorities change.
> >
> > At the end of the day, we need a file-based backup system, that is
> > relatively space efficient, supports remote network backups, supports
> > frequent backups, allows indefinite storage, and allows us to
> > completely purge directories.
> >
> > Ideally we don't want to change backup systems. Can rdiff-backup be
> > this system, with a little extra dev effort?
> >
> > If so, would anyone be willing to help us sort this out on a contract
> > basis? Need:
> > 1) fix current broken backup state
> > 2) fix existing delete tool, or write a new one. In either case tool
> > should be up to the standards of the rdiff-backup community, and
> > considered production ready.
> >
> > Thanks,
> > Brian Gupta
> >
> > [1] -
> https://lists.nongnu.org/archive/html/rdiff-backup-users/2019-11/msg00003.html
>
> I do have a fairly massive (~640 lines, ~550 non-comment) shell script
> that I agree is ugly, but which has worked fine for me for quite a few
> years (last modified 7 years ago) and successfully purges both specific
> files and entire subtrees from an rdiff-backup archive. The principal
> limitations are that it does not support long_filename_data (refuses to run
> if any found) and does not handle Mac resource fork metadata (ignores it).
> I'll send it to anyone who wants to try it, or I can put it up for comment
> and/or ridicule if someone would tell me where and how to do that. All I
> can guarantee is that if it eats any babies, those will be the first babies
> it has ever eaten.
>
> --
> Bob Nichols     "NOSPAM" is really part of my email address.
>                  Do NOT delete it.
>
>
>

-- 
Patrik Dufresne <address@hidden>