Prune should either disregard repository indexes, or not rebuild indexes twice #2227
Description
Output of restic version
restic 0.9.4 compiled with go1.11.4 on linux/amd64
How did you run restic exactly?
restic -r . prune
What backend/server/service did you use to store the repository?
Local, though this does not appear to matter.
Expected behavior
Prune completes successfully.
Actual behavior
Prune rebuilds the repository indexes in-memory but then appears to ignore these indexes, and tries to load the (missing) files from disk. When it gets to the garbage-collection phase, it therefore can't find any objects in the repository and fails. For example:
$ restic -r . prune
enter password for repository:
repository 26b51fe2 opened successfully, password is correct
counting files in repo
building new index for repo
[0:00] 100.00% 67 / 67 packs
repository contains 67 packs (4773 blobs) with 316.143 MiB
processed 4773 blobs: 0 duplicate blobs, 0 B duplicate
load all snapshots
find data that is still in use for 1 snapshots
tree 30649e56256d8418cd8b4f0c85f6ed048f6c4d04aa31e1fd28602df9956f125a not found in repository
github.com/restic/restic/internal/repository.(*Repository).LoadTree
/restic/internal/repository/repository.go:653
github.com/restic/restic/internal/restic.FindUsedBlobs
/restic/internal/restic/find.go:11
main.pruneRepository
/restic/cmd/restic/cmd_prune.go:191
main.runPrune
/restic/cmd/restic/cmd_prune.go:85
main.glob..func18
/restic/cmd/restic/cmd_prune.go:25
github.com/spf13/cobra.(*Command).execute
/restic/vendor/github.com/spf13/cobra/command.go:762
github.com/spf13/cobra.(*Command).ExecuteC
/restic/vendor/github.com/spf13/cobra/command.go:852
github.com/spf13/cobra.(*Command).Execute
/restic/vendor/github.com/spf13/cobra/command.go:800
main.main
/restic/cmd/restic/main.go:86
runtime.main
/usr/local/go/src/runtime/proc.go:201
runtime.goexit
/usr/local/go/src/runtime/asm_amd64.s:1333
Running restic rebuild-index first makes prune succeed:
$ restic -r . rebuild-index
enter password for repository:
repository 26b51fe2 opened successfully, password is correct
counting files in repo
[0:00] 100.00% 67 / 67 packs
finding old index files
saved new indexes as [a13538cc]
remove 0 old index files
$ restic -r . prune
enter password for repository:
repository 26b51fe2 opened successfully, password is correct
counting files in repo
building new index for repo
[0:00] 100.00% 67 / 67 packs
repository contains 67 packs (4773 blobs) with 316.143 MiB
processed 4773 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
found 4773 of 4773 data blobs still in use, removing 0 blobs
will remove 0 invalid files
will delete 0 packs and rewrite 0 packs, this frees 0 B
counting files in repo
[0:00] 100.00% 67 / 67 packs
finding old index files
saved new indexes as [e13b3d29]
remove 1 old index files
done
I would suggest that restic should either use the indexes it generated instead of the repository indexes, or not generate the indexes that it does not appear to use.
Steps to reproduce the behavior
- Create a repository.
- Run a backup to create a snapshot.
- Delete all of the files in the repository
indexdirectory. - Run
restic prune.