I’ve been using restic for years.
I regularly check to make sure that things are working OK by doing restore operations. I’ve yet to find an error! Restore operations have always succeeded.
But I just happened to discover that restic has a “check” command. So I ran it on my main repository:
>restic -r "f:\Backups\restic\My documents" -p "D:\My documents\sysadmin\resources\restic\my_documents_pwd.txt" check
using temporary cache in C:\Users\Chris\AppData\Local\Temp\restic-check-cache-2976399391
repository 5aa02dbc opened (repository version 1) successfully, password is correct
created new cache in C:\Users\Chris\AppData\Local\Temp\restic-check-cache-2976399391
create exclusive lock for repository
load indexes
check all packs
pack 6f029c10c8b2986691a4fd0cd325e2d4e6cedfdb89dc61a6c1731fb48f2b7af5: does not exist
pack c360d64de7e422e13a4a858a306e3d99ea39700755b12e3573ff3950cce772f3: not referenced in any index
1 additional files were found in the repo, which likely contain duplicate data.
This is non-critical, you can run `restic prune` to correct this.
check snapshots, trees and blobs
Load(<data/6f029c10c8>, 0, 0) returned error, retrying after 552.330144ms: open \\?\f:\Backups\restic\My documents\data\6f\6f029c10c8b2986691a4fd0cd325e2d4e6cedfdb89dc61a6c1731fb48f2b7af5: The system cannot find the file specified.
Load(<data/6f029c10c8>, 0, 0) returned error, retrying after 1.080381816s: open \\?\f:\Backups\restic\My documents\data\6f\6f029c10c8b2986691a4fd0cd325e2d4e6cedfdb89dc61a6c1731fb48f2b7af5: The system cannot find the file specified.
...
… and in fact it keeps repeating that same error endlessly, for minutes (and probably hours). The (progress) percentage never got higher than 2% over the 10 minutes I ran it.
The message is always the same: complaining about one file apparently missing from the repository. I obviously have now idea how this has happened.
The thing is, doing a restore operation at random is useful, but it obviously doesn’t tell you that the whole repository is “healthy”. In the case of the missing file above, that might indicate that one or many files (or possibly an entire snapshot) would not be able to be restored.
I’m intending to incorporate this “check” command into my weekly examinations of my restic repositories from now on.
But the bigger question is: what should I do about this “check” failure?
Is there anything which can be done? Is there any way to repair things? Is there any way to find out what snapshots (or parts of snapshots) are now damaged beyond repair?
later: also affecting “restic prune”!
Following the above suggestion given in the “check” command output, I tried to do “restic prune” on the above. And I get the same endlessly repeated error output (complaining about the same one file):
>restic -r "f:\Backups\restic\My documents" -p "D:\My documents\sysadmin\resources\restic\my_documents_pwd.txt" prune
repository 5aa02dbc opened (repository version 1) successfully, password is correct
loading indexes...
loading all snapshots...
finding data that is still in use for 69 snapshots
Load(<data/6f029c10c8>, 0, 0) returned error, retrying after 552.330144ms: open \\?\f:\Backups\restic\My documents\data\6f\6f029c10c8b2986691a4fd0cd325e2d4e6cedfdb89dc61a6c1731fb48f2b7af5: The system cannot find the file specified.
Load(<data/6f029c10c8>, 0, 0) returned error, retrying after 1.080381816s: open \\?\f:\Backups\restic\My documents\data\6f\6f029c10c8b2986691a4fd0cd325e2d4e6cedfdb89dc61a6c1731fb48f2b7af5: The system cannot find the file specified.
… carries on forever …
NB in fact the repository in the F: drive is very similar to another repository I have on my E: drive, an internal drive. That passed its “check” without errors. So I don’t have any massive problems. But it’d be nice to know what the response is if one day I find an error like this.