`max-unused unlimited` still repacks?

Maybe I don’t understand the new --max-unused flag, but the documentation seems to suggest that it won’t repack files if set to unlimited. Is something broken or do I not understand?

A partially used file is either kept or marked for repacking depending on user options.

--max-unused limit allow unused data up to the specified limit within the repository. This allows restic to keep partly used files instead of repacking them.

If the string unlimited is passed, there is no limit for partly unused files. This means that as long as some data is still used within a file stored in the repo, restic will just leave it there. Use this if you want to minimize the time and bandwidth used by the prune operation.

$ restic version
restic 0.12.0 compiled with go1.15.8 on linux/amd64

$ restic ... prune --max-unused unlimited
enter password for repository:
repository 01618c22 opened successfully, password is correct
loading indexes...
loading all snapshots...
finding data that is still in use for 11 snapshots
[3:40] 100.00%  11 / 11 snapshots
searching used packs...
collecting packs for deletion and repacking
[2:06] 100.00%  396416 / 396416 packs processed

to repack:       192147 blobs / 437.777 MiB
this removes     100645 blobs / 235.128 MiB
to delete:       542953 blobs / 655.164 GiB
total prune:     643598 blobs / 655.394 GiB
remaining:      7458132 blobs / 1.343 TiB
unused size after prune: 159.311 GiB (11.59% of remaining size)

deleting unreferenced packs
[1:33] 100.00%  870 / 870 files deleted
repacking packs
[0:10] 100.00%  113 / 113 packs repacked
rebuilding index
[0:55] 100.00%  282205 / 282205 packs processed
deleting obsolete index files
[0:31] 100.00%  195 / 195 files deleted
removing 114258 old packs

Because it has “to repack” and “repacking packs” it makes me think something is wrong, but the “unused size after prune” is greater than the 5% default. Is it repacking metadata?

Thanks for restic!!! If it’s a documentation issue I can submit a PR.

Right. This was changed in

The main arguments for it are: repacking tree packs

  • is cheap (usually those are cached)
  • reduces size needed for the cache
  • allows commands like recover to work as expected.

You are right, I did not change the docu to make this clear. Feel free to submit a PR which improves the docu!