Restic check not noticing buggy repo?

My repository got into a funny state, possibly from connections dying mid-backup. Then, after a restic prune (and possibly other commands, but I don’t think so), I observed the following:

$ restic backup --one-file-system /home/ecprice/
repository 765dfd55 opened successfully, password is correct
Fatal: unable to load index 8509865b: load <index/8509865b11>: invalid data returned

OK, so the docs warn about this error (https://restic.readthedocs.io/en/latest/045_working_with_repos.html) and say I should be able to tell with restic check:

$ restic check
using temporary cache in /tmp/restic-check-cache-866565214
repository 765dfd55 opened successfully, password is correct
created new cache in /tmp/restic-check-cache-866565214
create exclusive lock for repository
load indexes
check all packs
check snapshots, trees and blobs
no errors were found

Nope. This did go away with a restic rebuild-index, but I thought that if restic check passed, backups should proceed.

What backend does the repository use? Is it possible that this was the result of a one-time transport error? Did you try the failing restic backup command a second time or did you immediately run the successful restic check command?

Which version of restic is that?

We had a bug recently where truncated index files could end up in the local cache, this would exhibit the same behavior you’ve seen. For safety reasons, restic check does not use the local cache at all, so it would not have noticed the truncated file. And since it completed successfully I think the repository is fine :slight_smile:

1 Like