Cache folder is is extremely big! 😱

When you prune any of the repositories, :d: still needs to download all existing snapshot files for all repositories (not the whole data, just the chunks which store each revision details – the meta chunks). The /cache/chunks/ folder is used to store only these meta chunks that make up the snapshots.

If there are very many revisions or if some repositories contain large number of files, then the /cache/chunks/ folder can grow to a surprisingly large size, reaching even more than 150GB.

This is recommended to run prune from only a single repository, and use the -all option:

duplicacy prune -all -keep 0:365 -keep 30:70 -keep: 7:14 -keep 1:1 -threads 30
1 Like

As a palliative solution, it’s been a while since I’ve included a Rclone call in my scripts (rclone delete) with the pattern + */cache/**, pointed to the folders of Duplicacy files (preferences, filters, cache, etc).

Remembering that I have a bucket in B2 for each set of backups, so I have a more granular control over the executions, prunes, etc. This is one of the many advantages, IMHO, of having separate backups for each set of files, rather than large backups with all files.

The /cache/chunks/ folder can be deleted any time. It will only slow down the next operation a little bit as some chunks will need to be downloaded again instead of being loaded from the cache. Other than this there is nothing else to worry about.

Should this how-to be combined with Cache usage details?

1 Like

Could you clarify what β€œsome” means here? My optimistic reading is: there may be a large number of chunks in the cache which are (almost) never needed in practice, so their deletion will not matter. But some very few chunks are needed and will have to be redownloaded. Is this correct?

Does this mean we should run the prune command always with the -all flag?