Which restic commands are more efficient?

Getting Help
1

Which of the following is more efficient (regarding IO/cpu/memory usage):

restic forget --prune ...
restic forget --prune ...
restic forget --prune ...

Or

restic forget ...
restic forget ...
restic forget ...
restic prune

Does the --prune flag just run restic prune (or is it tuned to prune only the snapshots which just were forgotten)?

Second question:
Let us assume that there is 7 % unused space in the repository summing up to 50 G of (unused) space (so all of the commands below will remove 10G). Which of the following is more efficient when executed exactly once on an exact copy of the repository:

restic prune --max-unused 5% --max-repack-size 10G

Or

restic prune --max-unused 4% --max-repack-size 10G

Or even

restic prune --max-unused 1% --max-repack-size 10G

I am asking those questions because I run restic on my NAS and try to minimise the space the repos takes. But even more important than used space is the efficiency when executing the commands.

Thanks for your help.

2

restic forget without prune should be extremely fast. So, running a single restic prune after multiple restic forget is much faster than running multiple restic forget --prune.
(even better would be to use a single restic forget --prune - is there a reason why you need multiple forget runs?)

1 Like
3

The larger the --max-unused, the more packs can be kept which means the less packs need repacking. And repacking is the most time-consuming part in prune.

So prune --max-unused 5% will not be slower than prune --max-unused 4%. It however can be that both effectively do the same (e.g. because the ammount to resize is in both cases more than 10G and so they are equivalently limited by --max-repack-size)

4

Because I apply different policies (depending on host/path/tag). Those commands are executed multiple times a day via my backup script.

Could the following then happen(?): restic prune --max-unused 4% --max-repack-size 10G will free 10 G but might repack more packs which on average contain less unused blobs while restic prune --max-unused 5% --max-repack-size 10G might repack less packs but in total also frees 10G und thus will be faster.

But what will happen when the prune operation is executed regulary? I guess 4% will still be slower but over time the runtime should decrease (maybe :thinking:)

When I understand correctly I should prefer restic forget without the --prune flag.

5

No. IIRC, the amount of freeed space is not limited by any of these options. Because completely unused packs will be always removed, so in your example, 15G could be also freed. These options are all about about partly used packs. Those packs can be either kept, which is fast but does not free unneeded space. Or they can be repacked, which is slow, but does free space.

--max-repack-size does only limit the amount of packs which will be resized (within this single prune run), while --max-unused does also limit the packs which will be resized, but w.r.t. a tolerated global unused size. So it can be that both commands actually do the same because in both cases more than 10G would be repacked - but the limit option limits in both cases.

If a higher --max-unused option is chosen and this leads to less packs being repacked, the pruning is faster, but less unneeded space is freed - or vice versa.

1 Like