Stalwart Windows is using a lot of disk space

Questions
1

Your question

We have about 100 GB disk space for all stuff of Stalwart. Config running right now is RocksDB and files in blobs. When Stalwart is doing a auto purge, it doesn’t seem like it’s purging anything cause the disk usage is not going down. We only see the Storage raising up. So is it normal? Right now we’re at about 60GB

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

2

This is expected behavior with RocksDB and is normal, not a bug. A few points:

Purge removes data logically, but doesn’t necessarily shrink files on disk. Stalwart’s automated maintenance (dataCleanupSchedule, expungeSchedule, blobCleanupSchedule on the DataRetention object) deletes expired keys/records, but RocksDB is an LSM-tree store: deletions are recorded as tombstones and space is only physically reclaimed when RocksDB performs compaction on the affected SST files. Compaction happens in the background on its own schedule and isn’t guaranteed to run immediately after a purge, so “storage keeps rising” for a while is normal, especially under continuous write/delete churn.

Blob store files behave differently. If you’re using RocksDB purely for metadata and plain files for blobs, deleted blobs should actually be removed from disk by blobCleanupSchedule. If blob disk usage also isn’t dropping, check whether messages are actually being expunged (auto-expunge only cleans “Deleted Items”/“Junk” folders, controlled by expungeTrashAfter, default 30 days) versus just marked for deletion elsewhere, and check maxChangesHistory for changelog growth.

What to check on your end:

  • Confirm the DataRetention settings (dataCleanupSchedule, expungeSchedule, blobCleanupSchedule, expungeTrashAfter) are configured as expected and not disabled (null).
  • Give it a few cleanup/compaction cycles and watch trend, not a single snapshot, since RocksDB reclaims space asynchronously.
  • If space genuinely never drops over many days despite messages being deleted, that would be worth flagging as a bug rather than expected LSM behavior.

Reference: Maintenance and RocksDB backend.

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

3

Confirm the DataRetention settings (dataCleanupSchedule, expungeSchedule, blobCleanupSchedule, expungeTrashAfter) are configured as expected and not disabled (null).

I have checked, these are activated but i still don’t know if everything is working correctly.

4

For my setup a lot of space was wasted in the RocksDB LOG.old.* Files. U dont need them, and default is to keep 1000 of them. I now delete them via script.

5

Okay, so I will take a look at our test system to test this before i do on production system. All together is about 13 gb only log files. Total in use is right now about 40 gb, so why is that so much in use? the mailboxes are definitely empty. So one is about 18 mn but it’s the only one of 10 mailboxes which are filled. The other boxes are empty.

6

Check if messages are still being referenced in spam training, if they are, or have other references, they won’t delete until those references are gone.