Output of restic version

restic 0.9.5 compiled with go1.12.4 on linux/amd64

How did you run restic exactly?

Initialize a local repo
restic init --repo /home/vagrant/repo

Backup a test dir (clone of the openzfs repo, 85MB)
restic -r /home/vagrant/repo backup /home/vagrant/test

Remove a single data file to simulate data loss
rm /home/vagrant/repo/data/62/62d83f9eba8b34947941ed281ef9131887fd499d39b566c4c57f729093b2e071

restic -r /home/vagrant/repo check
Correctly complains about a missing file. But, I am still able to restore data from the repo, which is great (minus some of the files, obviously)

The problem starts here. Running rebuild-index appears to break the repo
restic -r /home/vagrant/repo rebuild-index
completes without error

A restore will now panic
restic -r /home/vagrant/repo restore latest --target /home/vagrant/restore/
enter password for repository:
repository 2fdae5c4 opened successfully, password is correct
restoring <Snapshot 765052de of [/recover] at 2019-07-12 12:56:59.426074427 +0000 UTC by vagrant@test> to /home/vagrant/restore/
Unknown blob 43dfd85e0eac10d828a4b596b27be76006d1c085838cdda2988276ee5e4dec1f
github.com/restic/restic/internal/restorer.(*filePackTraverser).forEachFilePack.func1
/restic/internal/restorer/filepacktraverser.go:21
github.com/restic/restic/internal/restorer.(*filePackTraverser).forEachFilePack
/restic/internal/restorer/filepacktraverser.go:32
github.com/restic/restic/internal/restorer.newPackQueue
/restic/internal/restorer/packqueue.go:52
github.com/restic/restic/internal/restorer.(*fileRestorer).restoreFiles
/restic/internal/restorer/filerestorer.go:118
github.com/restic/restic/internal/restorer.(*Restorer).RestoreTo
/restic/internal/restorer/restorer.go:252
main.runRestore
[..]

prune fails
enter password for repository:
repository 2fdae5c4 opened successfully, password is correct
counting files in repo
building new index for repo
[0:00] 100.00% 17 / 17 packs
repository contains 17 packs (3390 blobs) with 71.737 MiB
processed 3390 blobs: 0 duplicate blobs, 0 B duplicate
load all snapshots
find data that is still in use for 1 snapshots
[0:00] 100.00% 1 / 1 snapshots
Fatal: number of used blobs is larger than number of available blobs!
Please report this error (along with the output of the 'prune' run) at
https://github.com/restic/restic/issues/new

recover completes succesfully, but attempting to restore from the snapshot it creates also fails. Running a new backup shows no error, but it will again panic if you attempt to restore from it.

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

Reproduced it on a local repository, although I found the same issue while testing against an openstack swift repo.

Expected behavior

Be able to recover the rest of the data from the repository, and ideally, be able to re-upload only the missing data, not re-create the whole repo.

Actual behavior

Cannot restore data, or fix the repo (new backups will run without errors, but you're still unable to restore from these new snapshots)

Steps to reproduce the behavior

As described in the "how did you run restic" section

Do you have any idea what may have caused this?

Deleting a file within the "data" directory to simulate data loss.

Do you have an idea how to solve the issue?

No

Did restic help you or made you happy in any way?

Just testing so far, hopefully I did not miss anything obvious. I'll be happy to help troubleshoot this, if you think it is worth investigating.