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 <[email protected]> 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 <[email protected]>
