What to do with `restic debug examine --try-repair`?

Getting Help
1

Context: https://github.com/restic/restic/issues/1999

After a hash does not match id error during a prune, I was able to build a debug build of restic and find that the error could be repaired with a bit flip using restic debug examine --try-repair.

However, this command doesn’t actually fix the error, it just produced a file repaired-abcd.bin where abcd is the hash of the blob in question.

Does anyone know what I do with this file to fix my repo?

I’ve read all the issues that come up with a search for --try-repair, and I don’t see any relevant threads here on the forum.

Thanks in advance for any help.

2

@n8henrie I’ve added some instructions to the github issue.

1 Like
3

Thanks so much, I was able to follow your instructions.

For future readers, please check the instructions at the issue linked above.

The short version is that there doesn’t seem to be a way to remove just the bad blob or to force-overwrite the bad blob, so you have to operate at the pack level – extracting the entire (repaired) pack, removing the bad one, rebuilding the index, re-backing up the repaired pack.

EDIT: It doesn’t look like this discourse has the “mark as solved” option, let me know if I’m just missing it.

4

@n8henrie The topic was missing a category, I’ve taken the liberty to change it and mark it as solved.

I actually haven’t thought about surgically fixing just the broken part of a pack file. For a repository stored on a local filesystem that would be a possibilty. However, it’s easier to generically handle all the different types of pack file corruption by just salvaging the damaged one and writing a new pack file. Depending on the type of damage one might e.g. be unable to recover all parts of a pack file which in essence requires building a new pack file anyways. restic is also designed to write repository files only once and the afterwards only read from it until the file is deleted (WORM). That way it’s much easier to recover from damages or interrupted network connections.

5

That makes perfect sense. I was only thinking of it that way because the --try-repair seemed to only produce the repaired blob (without the rest of the pack) by default, so I thought that was the intended approach.

Thanks again for your help and time.