Questions about hardening borg repositories

[Ed Blackman]

I'm evaluating borg as a possible replacement of my current backup 
system that uses duplicity.  Generally, I backup system files for about 
90 days, and user files (with subdir-based exclusions) effectively 
forever.

However, borg's deduplication means that corruption within the 
repository would affect all of the archives.

My plan is to back up to a local disk, then do some scripting to create 
par2 parity files (Reed Solomon coding, 
https://github.com/Parchive/par2cmdline) for each segment, then sync the 
repository and parity files to Amazon S3, providing protection against 
individual file corruption and also failure of the local disk.

Questions:
- Is it safe to create files with non-numeric parts in the segment 
directory (eg "532.par2" and "532.volxxx+nnn.par2" for segment file 
532)?  par2cmdline has a heritage as a 'post binaries to Usenet' 
utility, so it wants to operate on files in the same directory as the 
parity files.  borg check --repair creates %d.beforerecover, so I think 
the answer is yes except for a negligible chance that borg will want to 
use those extensions.

- Do segment files ever change content between being first written and 
being removed?

- Is there any value in generating parity for or syncing the index.%d 
and hints.%d files?  It looks like they are rewritten on most operations 
and can be trivially regenerated by borg check.

- Are there any plans to add par2 support to borg?  Duplicity offers a 
par2 backend wrapper that creates parity files when duplicity creates 
files, removes the parity files when duplicity removes the corresponding 
core duplicity files, etc.  I didn't see a Github issue for it, but 
maybe someone has thoughts along that line.

-- 
Ed Blackman