Back up Mailu and upgrade with matching configuration
Inventory the selected Mailu services and persistent stores, test a consistent restore, and avoid mixing release-specific environment schemas.
Reviewed
Mailu deployments vary with selected services and storage. Derive the recovery set from your actual generated Compose project, not from a generic list that assumes every installation enables the same webmail/database components.
Capture the recoverable state
- Review the maintenance/upgrade guidance for your release in the official versioned docs.
- Preserve
mailu.env, Compose configuration, administrative/account data, mailbox storage, signing keys, and required feature-specific databases/state. - Use a consistent snapshot or documented stopped-service backup strategy for active writes.
- Store encrypted copies off-host and retain independent access to their keys and credentials.
Keep file ownership and required permissions intact. A database-only export is not a mailbox backup; a volume dump without configuration may not reconstruct the same deployment.
Rehearse the release change
Read upgrade notes and regenerate/migrate configuration only through the supported procedure. Restore a compatible copy to an isolated host, then verify accounts, old messages, new receipt, authenticated submission, and certificate handling.
Do not run destructive volume deletion as an upgrade step. An older image may not understand migrated data. Plan rollback with compatible backups, and prevent the restored test instance from competing for production mail or emitting old queued messages. After cutover inspect both mail-flow evidence and service health, not only the admin web page.