I have a script in which I run backup, stats, check and prune. I notice that it seems to be showing this message: “remove 4 old index files” for a while. What can/should I do?
❯ restic prune --verbose
repository 6d9f087d opened successfully, password is correct
counting files in repo
building new index for repo
[3:02] 100.00% 10531 / 10531 packs
repository contains 10531 packs (296857 blobs) with 50.185 GiB
processed 296857 blobs: 0 duplicate blobs, 0 B duplicate
load all snapshots
find data that is still in use for 14 snapshots
[0:16] 100.00% 14 / 14 snapshots
found 296857 of 296857 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% 10531 / 10531 packs
finding old index files
saved new indexes as [eafb91af 98356b6d 193562b2 3189d6eb]
remove 4 old index files
done
❯ restic rebuild-index --verbose
repository 6d9f087d opened successfully, password is correct
counting files in repo
[0:18] 100.00% 10531 / 10531 packs
finding old index files
saved new indexes as [a2dbfea5 c924c704 4b8b0464 62211bf1]
remove 4 old index files
❯ restic check --verbose
using temporary cache in /tmp/restic-check-cache-493225142
repository 6d9f087d opened successfully, password is correct
created new cache in /tmp/restic-check-cache-493225142
create exclusive lock for repository
load indexes
check all packs
check snapshots, trees and blobs
no errors were found
Nothing. This (and the immediately preceding line) are informational messages indicating that restic replaced the “old” index files with new (possibly updated) versions, as you requested by running “rebuild-index.”
When you do a prune operation the index is rebuilt and saved even if no other changes have been made. This is most likely due to the fact that the first step in a prune is to rebuild the index.
If you do not do a forget operation prior to the prune there is generally no need to do a prune. If prune does not report any errors there is no need to do a rebuild-index.
Well, yes. Every time you explicitly (via restic rebuild-index) or implicitly (via, for example, restic prune) ask restic to rebuild the index, restic will use existing information in the repository to do exactly that. This means that it will create new index files, save them, and then delete the old index files (in that order). The log output that seems to concern you e.g.
saved new indexes as [a2dbfea5 c924c704 4b8b0464 62211bf1]
remove 4 old index files
is the expected behavior and simply confirms that this series of operations succeeded.
Possibly I’m missing your point; if so, perhaps you could explain exactly why this concerns you?
To add to @doscott’s comment, there is generally no reason to run a prune operation unless a preceding forget operation has removed one or more snapshots, and generally no reason to explicitly run a rebuild-index operation at all. Doing so won’t hurt anything, but takes time and resources while serving no purpose. There are exceptions, of course–mostly in cases where you need to repair a damaged or corrupted repo–but prune and rebuild-index are not something you would need (or even want) to do every time you create a new snapshot.
saved new indexes as [a2dbfea5 c924c704 4b8b0464 62211bf1]
remove 4 old index files
saved in past-tense suggests restic did something. remove in present-tense suggests the user needs to do something, particularly after the past-tense. “I saved, now you need to remove” kind of. Like “go shopping” tells someone what to do (imperative).
Informational messages are usually given in past-tense (-ed) or continuous (-ing) form.
Exactly!
It says: “remove 4 old index files” not “removed 4 old index files” or “replaced 4 old index files”.
Saying remove means that is to be removed by me. That is what I undertood.
I think that there’s room to rephrase some of the messages, e.g. “remove 4 old index files” -> “removing 4 old index files”. Also some of the confusion comes from there not being a “done” at the end of rebuild-index.
Regardless, I think a PR that fixes these messages might be a good idea, but for now I would suggesting holding off on that until the next release as there might be a bunch of changes to the code in the places where this would be fixed. I suggest opening an issue (if there isn’t one already) detailing the messages that should be rephrased. Then we have something to track and a PR can be made when it’s time for it.