I just ran a forget on a b2 repo with the --prune flag and was somewhat surprised how quickly it ran - previous attempts at running prune had taken several hours.
I checked the repo online using BackBlaze’s browser interface and the amount of data was the same - I didn’t expect a dramatic drop since it was only metadata being removed - but some sort of drop in the amount of data was expected - especially as there is about 100G of metadata in there.
So I ran a simple prune to see what would happen and, as previously, it began a long and slow process of counting files and building a new index (currently 0.47% through after 4 minutes).
The length of time taken by the prune isn’t the issue - it’s the fact that using the --prune flag on the forget command didn’t seem to have made any difference to the process at all…
@phunni, it can and will happen that forget doesn’t forget any snapshot. For example, that happens once every week for my forget schedule. In that case prune won’t be run at all. But, you can always force it with restic prune command, though I suspect it won’t do anything useful, just spend some time confirming the fact that nothing needs to be deleted/rewritten.
If you can attach the output of your forget --prune command, we can easily confirm the above fact, or dismiss it, in case you encountered a genuine bug.
Ah, I see, you actually didn’t use scheduling, but explicitely mentioned what snapshots to forget. I can’t be sure, but I think that happened to me once.
And, yes, if you can repeat it, then I’d consider that a bug worth reporting to Github issue tracker.
In the meantime, you’ll need to do it in 2 steps:
restic forget 7634a561 …, and then
restic prune
In this case it won’t try to be too clever, and will run that prune step no matter what.
