-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Add option to check for bit rot during backup creation #805
Description
There is currently no way of knowing if the original files deteriorate.
restic backup skips files based on mod time. Bit rot will not be detected at all, but the backup will contain the original file. If the owner modifies the file without discovering that the file is degraded, or restic backup --force is run, restic will happily backup the new file. At the time when the owner discovers that the file is degraded, it will be very hard to find and recover the correct bits. Worst case scenario, the file is lost due to backup pruning.
restic backup --force hashes all files, regardless of mod time. Bit rot will result in a new hash, and restic will interpret this as a normal modification and backup the file. The owner will be none the wiser, and will similarly have problems when the bit rot is detected.
I suggest implementing a third option, similar to restic backup --force that checks mod time to determine if the file has been changed intentionally. If the file is modified without a modified mod time it would log or err out.
(This could also be extended to verify other meta data, such as checking that the modified date is not earlier than the one recorded in the previous backup.)
This might be out of the scope of a backup program, but if we are already hashing the files, and recording the previous hashes, most of the work is already done.