Duplicacy storage amount not matching actual storage amount

Support
#1

I’m backing up to Backblaze. Backblaze states I’m using 1,162.6Gb. this is the only service I have using backblaze

However, Duplicacy states my storage usage on Backblaze is 700.74G

I have run an -exaustive purge.

Any idea why these numbers are so different? is there a way to clean it up, short of clearing out the bucket and trying again?

#2

When was the last time you run a check? This is the only time Duplicacy Web updates its stats.

Double check the logs - it should have something like INFO SNAPSHOT_CHECK Total chunk size is <blahG> in blah chunks at the top.

#3

It runs a check after every backup job.

Will check logs when I get home. I might make a new B2 container for each app so I can manage the backups better.

#4

2026-01-21 21:17:59.482 INFO SNAPSHOT_CHECK 8 snapshots and 112 revisions
2026-01-21 21:17:59.485 INFO SNAPSHOT_CHECK Total chunk size is 668,688M in 137008 chunks

Backblaze says:
Current Files: 226,731
Current Size:1,186.7 GB

#5

You can try running prune with -exhaustive flag (very slow) to purge orphan chunks if any.

#6

I have been running the prune with the following arguements:
-keep 0:2000 -keep 90:700 -keep 30:400 -keep 7:90 -a -exhaustive

Running prune command from /cache/localhost/all
Options: [-log prune -storage BackblazeBackup -keep 0:2000 -keep 90:700 -keep 30:400 -keep 7:90 -a -exhaustive]
2026-01-21 22:23:11.221 INFO STORAGE_SET Storage set to b2://[REDACTED]
2026-01-21 22:23:12.155 INFO BACKBLAZE_URL Download URL is: [REDACTED]
2026-01-21 22:23:12.618 INFO RETENTION_POLICY Keep no snapshots older than 2000 days
2026-01-21 22:23:12.618 INFO RETENTION_POLICY Keep 1 snapshot every 90 day(s) if older than 700 day(s)
2026-01-21 22:23:12.618 INFO RETENTION_POLICY Keep 1 snapshot every 30 day(s) if older than 400 day(s)
2026-01-21 22:23:12.618 INFO RETENTION_POLICY Keep 1 snapshot every 7 day(s) if older than 90 day(s)

#7

I can’t think of anything contributing to such a drastic difference in object count as seen by duplicacy vs b2 other than:

  • fossils
  • hidden/deleted objects that B2 for some reason keeps for versioning reasons. I’m not familiar with hour b2 works.

To clean up the former, stop all schedules, ensure nothing else can be touching the storage and run this only once:

prune -a -exhaustive -exclusive.

This shall get rid of orphans immediately.

Don’t. There is no reason to use -exhaustive routinely. You only use more API calls and prunes take longer. No benefit in return. It’s useful to clean up in some corners cases.