Plan Stalwart backups and version upgrades
Inventory storage, directory state, keys, and configuration and prove recovery before updating an integrated mail deployment.
Reviewed
Stalwart’s storage flexibility means “back up the container” is not a complete recovery plan. Inventory the actual data, blob, directory, indexing, and configuration services used by this deployment.
Define the recovery set
- Review the storage/security sections linked from the official documentation for the installed version.
- Record which stores contain authoritative mailbox data and which indexes can be rebuilt. Follow each backend’s consistent-backup requirements.
- Preserve account/directory configuration, domain settings, signing/encryption material, and deployment manifests with appropriately restricted access.
- Keep an encrypted off-host copy and identify the credentials needed to restore it independently of the failed host.
A replicated store is not protection from accidental deletion or a bad migration replicated to every node. Choose recovery objectives and test restoration, not just backup job completion.
Rehearse an upgrade
Read release notes and supported upgrade paths before changing the pinned version. Restore into an isolated environment, check mailbox/content integrity, and test authentication, receipt, submission, and client access without publishing production MX.
Database/configuration migrations may make an old binary incompatible with the new state. Rollback needs a compatible backup and explicit delivery reconciliation, not simply an older container tag. During production maintenance monitor queues and avoid letting restored copies independently send old queued messages. Keep the operator decision and expected downtime in the runbook.