Back up and upgrade docker-mailserver without losing mail
Preserve configuration, signing material, mailbox data, and state and rehearse an image upgrade with a compatible recovery copy.
Reviewed
A container can be replaced; mail cannot. Inventory every mounted configuration, mail, and state path before upgrading docker-mailserver, including changes introduced by optional features.
Capture a consistent recovery set
- Review maintenance/security guidance for the installed release in the versioned documentation.
- Preserve Compose/environment configuration, account/alias files, DKIM keys, mailbox data, and required state with correct ownership.
- Use a consistent snapshot/backup procedure appropriate to running mail services, not an unexamined copy during writes.
- Encrypt and move backups off-host; verify the restore credentials and available disk capacity.
Logs help diagnose incidents but are not a substitute for mailbox and account backups. A copy of the image does not contain the mounted data.
Rehearse the upgrade
Read release notes, select the matching documentation, and restore a compatible copy into an isolated environment. Test account authentication, existing mail, new receipt, submission, filtering, and signing before updating the production image pin.
Avoid destructive volume-removal commands during routine maintenance. Rolling back an image may not undo data/configuration migrations. Keep queue reconciliation explicit so an old restored spool does not send duplicates alongside the current instance. Confirm normal mail flow and monitoring after the planned restart.