So what’s the upshot of getting pack FOO: does not exist during “restic check”? It’s still running, and hasn’t gotten to the snapshots/trees/blobs part yet. Just prior to the check I ran “rebuild-index” successfully.
Reading the code, it seems to print when there is an index that refers to a pack that does not exist on the backend (I checked a few of the mentioned packs, and the log message is correct: they do not exist in the bucket).
I guess this means some number of my snapshots are now missing data? Is there any way to map this to actual snapshots and files/data? I’m wondering if this is recoverable in any way, or I should just abandon this repo (I have a separate good, verified local restic backup).
While it would be nice to avoid having to re-upload 200GB to the cloud again, I don’t want to be in a situation where there are “holes” in the snapshots. Maybe the best I can do is a fresh backup, then “forget” the snapshots prior to that backup, followed by prune? Any better way to get to a known good state with this?
FWIW, this is on the remote b2 repo that I had run “rebuild-index, check, prune” recently with my XDG_CACHE_HOME on a failing local drive. I interrupted it during “prune” when I realized that the drive was failing. So it’s not surprising that there is some damage in the repo, and not the fault of restic.
restic check reports that a pack is missing when it is referenced in an index, but not present in the repo any more. That should not happen during regular usage, and especially not after rebuild-index is run, which re-builds an index from the list of pack files that are contained in the repo.
So if this message is still present after a rebuild-index, there’s something wrong…
It’s on my todo list, but not done yet. In principle, restic has all that information, but it’s not implemented yet. Sorry.
Yes, there is a way, but you need to follow the steps exactly:
run restic rebuild-index
remove all snapshots with restic forget, either manually or by using forget --keep-last 1 and then remove the last snapshot manually
then run restic backup again
as the last step, run restic prune, this will remove data that is not needed any more
When the new backup is stared, restic will first download the index, so it knows which blobs (parts of files) are already present in the repo. Those blobs won’t be uploaded again. But if any of the blobs that were in the file that is missing are found, those will be uploaded again. Running prune after the backup will get rid of all unneeded data.
Oh, that also works. It may even happen that the repo is repaired, when restic finds the blobs that are missing and re-uploads them…
I agree, but we strive to handle these situations better, so I see a lot of room for improvement (eventually)