Compacting MBs into GBs?

Looked at my longer-than usual backup messages tonight and found this:

Downloaded 56 file(s) with a total size of 262.09 MB, deleted 111 file(s) with a total size of 263.99 MB, and compacted to 92 file(s) with a size of 2.23 GB, which reduced storage by 19 file(s) and -2122140792 bytes

I’m confused about the following:

  1. why are files being deleted when I have keep set to unlimited? Granted, filter changes have caused folders to be dropped from the backup but no changes have been made for at least 3 backup runs - and with unlimited that shouldn’t cause cleanups, right? (Oops?)
  2. the word “file(s)” sometimes seems to mean dblock (1st, 3rd, & 4th usages) and sometimes seems to me actual FILE (2nd usage). (Just confusing, I think)
  3. somehow 262.09MB of files got “compacted” down to 2.23GB of files? (perhaps reporting the wrong number in the “size of XXXGB” section?)
  4. negative bytes count. (I’m assuming this is just a side effect of #3)

Oh, and I’m using 2.0.2.9 canary.

Most likely this is the “small files” part of the compact scheme. You should see in your log “compacting because …” explaining why.

The small file compaction is done to reduce the number of files. Say you run a backup each hour, and just a tiny amount of data is changed. This will litter the remote store with small dblock files.

To counter this, the compact process checks how many small files are found, and kicks in compacting if there are too many.

I think the first part is “downloading 56 dblocks, deleting these (+56 dindex = 112)”.
The second part is saying that the new file store is “92 files” (was 92 + 19 = 111 before), but the last number is probably 263mb - 2.23GB which is completely wrong way to calculate it …