Restic repository shows packID does not match

Getting Help
1

Hi,
I am using restic latest version 0.16.2 to backup nextcloud and onlyoffice data. few days back our backup server file system(xfs) got currupted and it starts showing read error for /data folder in restic repository. Later i have repaired the file system but while running check command on repository it shows errors such as fatal: repository contains error.
Later i have followed the documentation given at this link
Troubleshooting — restic 0.16.2 documentation

Now when i run the command-
restic repair snapshots --forget
it says no snapshots were modified , however while running following command-

restic check --read-data

it shows packID want [abc] , got [xyz]

finally process completes and shows:
fatal: repository contains error.

please help me to recover the data from repository.

os- rhel 8
restic version- 0.16.2

2

Paste the complete output of the restic check --read-data command please. You can wrap it in ~~~ on their own line before and after the output to make it format nicely, e.g.:

~~~
text
here
~~~
3

Repairing the repository will only be possible with a limited amount of data loss.

With restic 0.16.2, the following approach should minimize data loss. From all packID want [abc] , got [xyz] lines, extract the abc IDs (the ids should each be 64 characters long), then append all of them to RESTIC_FEATURES=repair-packs-v1 restic repair packs. This will result in a command like RESTIC_FEATURES=repair-packs-v1 restic repair packs 01234567... 12345678.... If that command works successfully, then run restic repair snapshots --forget to repair the repository. Afterwards restic check --read-data shouldn’t report any further errors.

If the restic repair packs command fails (don’t worry, it won’t damage the repository even if the command panics), then you’ll have to remove the damaged pack files manually. Remove the files with the abc IDs from the data folder of the repository (please keep a backup copy), then run restic repair index and finally restic repair snapshots --forget.

4

Thank you very much for this post. It helped me a lot. In case another user could benefit, I’ll describe my experience.

I wanted to test restic with an initial backup. restic -r $repo backup $data, ~40GB to usb. So no network issues were involved, but my host system did sleep while making the backup. :man_facepalming:

restic -r $repo check --read-data revealed ‘Pack ID does not match, want $sha256a, got $sha256b’ errors.

restic -r $repo restore $snapshot1 indicated ‘ignoring error for $file: ciphertext verification failed’ errors.

Naturally the actual data from this restore was incomplete (missing or broken files).

I still had access to the original data. But after making a second backup, restic -r $repo check --read-data still showed ‘Pack ID’ errors. (I guess I don’t have the results of restic -r $repo restore $snapshot2, presumably they would still show ‘ciphertext verification failed’ errors).

I hadn’t yet discovered the restic backup --force flag, which can turn off change detection and rescan all files.

However, by following Michael’s instructions (removing the damaged pack files manually, etc.) restic check --read-data successfully returned ‘no errors were found’, at the cost of the additional data that relied on the deleted pack files. I made a third backup with correct pack files, then restored all of the original data. :100:

I do have a question. I used restic -r $repo restore $snapshot --no-cache for the successful restore, but I’m not sure if that is necessary. Should I run restic --cleanup-cache in order to not use the --no-cache flag on subsequent restores?

I’ll be interested to see the progress of Add feature flags.

Thanks for all the hard work!

1 Like
5

restic explicitly asks the OS to really, really write files to disk before using those files in a snapshot. Either the filesystem or the USB drive ignored that request and thereby caused the repository damage.

--cleanup-cache only removes old cache folders. The cache folder is automatically recreated (and filled from the repository) unless --no-cache was specified.