Years ago I made a good decision and a bad one. The good one was backing up my data using restic, of course! The bad one was using a filesystem without checksumming (and thus, vulnerable to bitrot). I hopefully solved that problem by moving my data to btrfs. But in the process I found at least two files have bitrotted in the past 5 years. How many more are there?
I’d like to find out by running an integrity check of my local data against restic’s index, without having to download the entire restic repo. I can hash my local data easy. And restic should have hashes for blobs covering every byte in every file. So it seems possible in theory. But how could I actually do it?
The “check” command tests the repository for errors and reports any errors it
finds. It can also be used to read all data and therefore simulate a restore.
By default, the “check” command will always load all data directly from the
repository and not use a local cache.
If you want to check your entire repo for issues, there is no getting around to read in all files from the repo with the --read-data or --read-data-subset flag.
@moritzdietz As far as I understood the question, it was not about checking a repository for integrity but instead about verifying the integrity of local files against a repository content.
@iqktp Check this topic (it is about verifying restored data against the repository): Verifying restore
