Maintain Mail-in-a-Box backups and supported upgrades
Verify encrypted off-host recovery, preserve backup credentials, and avoid unsupported operating-system or component upgrades.
Reviewed
Treat the appliance’s supported upgrade and backup procedures as one operating model. An arbitrary distribution upgrade can break assumptions even when individual packages appear healthy.
Establish independent recovery
- Review backup/maintenance guidance linked from the official setup guide.
- Configure the supported off-host destination and preserve backup encryption/access credentials outside the appliance.
- Check job results and backup freshness rather than assuming an enabled schedule proves success.
- Record the supported OS/appliance versions, hostname, DNS delegation, and access needed for host replacement.
A backup encrypted with a lost key is not recoverable. Keep that key in the approved secret store, not in a public runbook or an email to a mailbox hosted only on the failed appliance.
Rehearse restoration and upgrades
Restore a copy to an isolated supported host, verify accounts/messages and administrative access, and prevent the test instance from receiving production mail or replaying queued sends. Use controlled client tests to verify recovery.
Read current upgrade instructions and compatibility notes before running the supported installer/update path. Do not independently replace core service configuration or upgrade the OS beyond what the project supports. After production maintenance, review system/DNS checks and verify receipt, retrieval, submission, and certificate renewal. Keep rollback tied to a compatible full recovery set rather than a guessed package downgrade.