Hi,
When running a restic check, sometimes I get a few “Pack ID does not match” errors. When running a check a second time, these errors are gone.
So, apparently, these “Pack ID does not match” errors are, at least in my scenario, temporarily download errors from the repro I guess. I know, in a perfect world, it shouldn’t happen but it does.
Would it be possible, perhaps with an optional switch, to let restic check such pack id’s a second time during the same check? That way, if succeeded it wouldn’t cost me a full second check on the whole repository.
If you have that type of transient errors, there’s an underlying problem that needs to be addressed instead of restic just retrying the check for the parts that errored. Do you have any idea what it might be?
Perhaps run some memory tests? Also, please specify the restic version (and try with the latest one, 0.13.1) as well as what backend you’re using.
Hello @rawtaz and thank you for your reply.
I am using restic 0.13.1 compiled with go1.18 on linux/arm with Jottacloud as a backend.
I think Jottacloud sometimes produces an error or incomplete download or something like that.
P.e. the last check with readdata 2 from 421330 packs gave a “Pack ID does not match” error.
Downloading those packs manually and checking the sha256 results in no error.
Occasionally I have had this before with a restic check.
restic explicitly asks for the full file size when checking the file content. So an incomplete download cannot be the cause. There must be some data corruption involved.
will be able to work around some cases. But essentially it would be a good idea to check whether the local hardware has problems or not.
Thank you, will try to do that. Although I need to find a way so that paths and ownerships of the source data look the same on a different system, so the metadata looks the same for restic.