Confused about --prune

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. :slight_smile:

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.

Here’s the output suggesting it did, in fact, forget a number of snapshots:

./restic/restic -r b2:redacted:video forget --prune 7634a561 891898dc 5147f843 8390d360 98448ec3 8bfbb70d 1f07f0e0 103f0694 7a1db29d
enter password for repository: 
removed snapshot 7634a561
removed snapshot 891898dc
removed snapshot 5147f843
removed snapshot 8390d360
removed snapshot 98448ec3
removed snapshot 8bfbb70d
removed snapshot 1f07f0e0
removed snapshot 103f0694
removed snapshot 7a1db29d

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.

Congratulations, you found a bug! The --prune argument to restic forget did not check for manually specified IDs, so prune never ran in that case.

Will be fixed in #1317

1 Like