Hi @D-i-t-gh. Mailpit shows info-level messages by default, which displays errors, warnings, and info messages while hiding debug messages. Currently, only startup messages are classified as "info," while VACUUM actions are logged at debug level - since most users don't need visibility into this operation.

To track when Mailpit runs a VACUUM, you'd need to enable debug logging and search for "vacuum completed in." There's no other way unless I change the logging level for that scheduled task. However, doing so would raise the question of why I shouldn't also promote auto-delete logs to info level, which will then become quite verbose on busy servers as deletions happen far more often.

Here's how VACUUM works: When messages are deleted, their "deleted size" is recorded in the database. Once the total deleted size reaches ≥ 1% of the database size and the database has been inactive for 5 minutes (no messages received, deleted, API access etc), a VACUUM is triggered. Since VACUUM is CPU and disk-intensive, it's designed to run infrequently and during low-activity periods.

Just to be clear, I'm not opposed to changing the VACUUM logging to info, I'm just not sure whether it would be of any use to you given that you actually have no control over it.

Thanks for your answer. A VACUUM is a much heavier operation than deleting. Suppose someone does frequent online backups - it will fail when a VACUUM is running. Also as much as twice the size of the original database file is required in free disk space. This is not the case if Mailpit runs the auto-deletes.

I agree it would be nice to also have control over the time when VACUUM is executed. Maybe an option "run VACUUM at startup" could be implemented without major code changes? This way, I could just schedule a restart to run the VACUUM at a time window when nobody uses the service and no backup is running.

Yes, a VACUUM is much heavier than a deletion because a deletion leaves empty space in the database file, whereas a VACUUM completely rebuilds the database.

1. Backups of any in-use SQLite database are always prone to issues if there are any changes to the data within that time. The only way to ensure safe backups would be to take filesystem snapshots and backup the snapshot, or alternatively to first shut down Mailpit, take the backup, and the restart Mailpit again (see below for a suggestion).
2. I'm afraid a "run VACUUM at startup" is a very bad idea in case there is an issue (eg: the OS runs out of memory, storage space, corrupt database etc) because Mailpit may end up crashing and restarting automatically - which will continue to thrash the system in a "boot loop".

I think that the first thing you should consider trying is manually running a VACUUM (as I'll explain below) at a scheduled time. Note that this would involve Mailpit downtime, although that's technically also the case when it runs automatically too (Mailpit will not respond until the VACUUM is complete):

1. Shut down Mailpit
2. sqlite <database-file> "VACUUM" && sqlite <database-file> "DELETE FROM settings WHERE Key='DeletedSize'"
3. You should consider making your backup at this point (optional).
4. Start Mailpit

If this solution works for you, then I will also consider adding a startup option to disable auto-vacuum. I don't think it will be necessary because deleting more than 1% of a very large database is actually a LOT of deleted emails, and if you're running the process above you're actually "resetting" the delete count every day anyway.

Thanks, your solution works well, so having an option to disable auto-vacuum would be very nice!

Backups of any in-use SQLite database are always prone to issues if there are any changes to the data within that time

I have made some tests with running sqlite <source-database-file> ".backup <backup-database-file>" on a Mailpit database, while sending frequent mails to it, and I have had no issues so far (verified with PRAGMA integrity_check), it only takes very long to finish. Also the official documentation for the online backup API reads as if it is rather uncritical. However, I agree using your solution should be the safest way to make a backup.

I've added this feature to v1.29.5 - --disable-auto-vacuum (flag) or MP_DISABLE_AUTO_VACUUM=true (environment).