restic: Data blobs seem to be missing, prune aborted

Output of restic version

restic 0.11.0 compiled with go1.15.3 on windows/amd64

How did you run restic exactly?

.\restic.exe forget --cache-dir ... -r rest:http://... --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --keep-yearly 75 .\restic.exe prune --cache-dir ... -r rest:http://... .\restic.exe check --cache-dir ... -r rest:http://... --read-data

What backend/server/service did you use to store the repository?

REST backend on a Linux system, formerly sftp to the same system; I have checked the Linux filesystem and RAID array and there are no physical or filesystem errors that would cause this problem.

Expected behavior

No errors or issues

Actual behavior

Running prune reports:

find data that is still in use for 192 snapshots
[43:00:26] 100.00%  192 / 192 snapshots
Fatal: [<data/646827e1> <data/da50cbe1> <data/7aa023ab> <data/4016966d> <data/a8b17e2e> <data/ae39f37d> <data/1c7f8046> <data/1aff2452> <data/aeccbf74> <data/36bb177f>] not found in the new index
Data blobs seem to be missing, aborting prune to prevent further data loss!

Running check confirms that blobs have gone missing.

Steps to reproduce the behavior

N/A; I have a 12TiB repo that I use for active backups and I haven’t played around with it.

Do you have any idea what may have caused this?

The repo seemed to be in fine condition prior to forgetting snapshots, and I’d run prune recently on it without error. This points to a combination of forget + prune as the source, but I can’t verify or test that.

Do you have an idea how to solve the issue?

I have rebuilt the index and I am still getting missing blobs when I run check (this time from Linux). I’d love to get things back to a stable state and I still have access to the original files that make up those blobs.

Did restic help you today? Did it make you happy in any way?

I generally love restic, but I’m not so thrilled at the prospect of data loss.

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 1
  • Comments: 19 (8 by maintainers)

Most upvoted comments

That sounds like the repository is now repaired 😃 . prune should now work without errors.

I’m running prune now and I have the REST server’s container writing to an overlay filesystem so I can see if it changes/breaks anything without causing potential issues with the repo. I wish I knew what had caused this corruption in the first place.