I was apparently caught up in the bug effecting earlier 1.6.x versions of Restic when using --compression max, so following the advice found here, I ran restic repair packs. I’m not sure of how well it worked yet, but the first thing I noticed is that I went from 1006 index files to just 168. I have a full Btrfs snapshot of the repo, so I’m not worried about having already lost data, but this is alarming.
Why should it be alarming? Did you see a lower total size of all index files? That would be alarming. Alone the number of index files doesn’t tell much as long as all pack files are correctly covered by the index.
2 Likes
… That is an excellent point. I feel pretty stupid.
No it is not smaller.
dont try to fix it, you can never fully trust that repo again, just throw it away and make a new one.
Actually it is an optimization to “repack” index files, i.e. putting the index entries of more than one index files together in a new one. Any operation that anyhow has to touch the index should take the opportunity to do this!
There’s nothing in here that would substantiate such a harsh reaction. The restic repository format is designed such that it is possible to detect and recover from data corruption in the repository.
If restic check --read-data does not report an error then the repository is ok. If you want to be super thorough, then pass the --force option to the next backup run, that will read all files again.