Output of restic version

restic 0.8.1
compiled with go1.9.2 on linux/amd64

How did you run restic exactly?

restic -r b2:my-bucket-name forget --prune --tag mytag --keep-weekly 2

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

Backblaze B2

Expected behavior

I'm using restic to back up some data to Backblaze B2. In a single repository I have a large filesystem (~ 100G) and a small directory (approx 50M). I used restic forget --prune to remove some snapshots of the smaller directory, which triggered a re-indexing operation.

I expected the reindexing would be a relatively short process because the snapshots I removed were small.

Actual behavior

The reindexing operation triggered by --prune seems to involve the entire repository, and resulted in a very long running process. This caused a number of problems:

• The entire repository is locked for the duration of the reindexing process, which means I am unexpectedly unable to interact with the repository.
• Since I'm using a service that meters data transfer, I am concerned that if re-indexing requires a lot of i/o that this will be a financially expensive operation.

Do you have an idea how to solve the issue?

One option is perhaps to configure backblaze + b2 to use one repository per bucket. This seems to run counter to the design of restic, but maybe it's the best way to prevent small changes from triggering time- and money-intensive results. If this sounds like a good idea, maybe it should be mentioned in the documentation.

I would prefer an option that would allow a prune operation on a mixed repository like this to complete in a shorter amount of time, particularly when the changes are "small", but I don't know anything about how restic is managing the index right now so I'm unable to suggest a practical solution.

Separately, a lock-free solution or at least one that would permit read operations (particularly restores) during the reindexing process would be great.

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

Other than my surprise at the run time of the prune operation I've been very happy so far: it's been very easy to work with and the command line seems sane.