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

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.