Hi David,
I have a similar setup, and a similar concern. Don’t know if my current solution is the best, but I think it addresses the risk sufficiently for me. I’m interested to see what other people do.
I take advantage of the fact that restic never alters repo files after creation. So when I copy to an off-site s3 bucket, I use rclone in the following way (I would guess similar options are available with other copying methods):
- Typically run it with
-v copy --immutable. This won’t delete any files on s3 that are missing from the source, and will refuse to overwrite an existing file, throwing an error if the files don’t match (as would be the case if the source files got encrypted with ransomware). Worst-case, post-attack this would mean that any snapshots younger than the previous s3-copy operation would be unusable (which they would be, anyway). - After a prune, run it with
-v sync --immutable. This will still error on changed files, but will also delete any files on s3 that were removed from the source during the prune. So check a dry-run output first to be completely reassured that your entire repository isn’t about to be deleted.
For non-malicious corruption risk, I use par2 error-correction files. While I could find such corruption with hash-checking, the par2 approach means I’d have a chance to correct it after the event.
I then trust my fortnightly restic check --read-data will pick up problems in enough time to recover.