Understanding Cache Size

Support
#1

Hey folks,

I’m just wondering about the size of the cache vs. backup. I have a device which is backed up, and then if I add the storage to another device + restore 1 file of about 150MB, the cache ends up as 1.4GB for a 70GB repository with only 1 revision:

image

image
image1193×168 11.4 KB

I have another backup which is ~2TB, and with 47 revisions, and the cache on that is only just hitting 1.4GB:

image
image728×54 3.41 KB

Any reason why the Duplicacy backup might be so much larger, proportionally? I would like to switch to using Duplicacy for everything, but if it grows at this same rate, the cache size will be too large for me to use unfortunately :frowning:

#2

Only metadata chunks are stored in the cache, and the amount of metadata chunks is proportional to the number of files in a backup, not the total file size.

Moreover, if you run only backup jobs from a repository, the cache only stores the metadata chunks in the latest backup. But if you also run prune jobs, then metadata chunks from all existing backups will remain in the cache.

#3

Okay, so in this instance the repository has 485,496 files in, whereas the Borg repo only has 200,105 in it. So, without knowing how the Borg repo design handles metadata/caching, it would seem perhaps the Duplicacy solution is better at this than Borg?

Follow up question: is the metadata chunking a fixed size per file? I.e. can I calculate cache size based on number of files, or is there some variability in this?