Back up iRedMail and follow its ordered upgrade path

iRedMail is a host-installed stack, so a complete backup spans more than one application’s files. The account backend, mailbox data, and generated service configuration must agree after recovery.

Inventory the actual recovery set

1. Use backup/restore and upgrade guidance in the official documentation for the deployed edition/version.
2. Back up the selected SQL/LDAP account backend using its consistent procedure.
3. Preserve mailbox storage, signing keys, relevant filtering/webmail data, configuration, and any encryption/access credentials required to restore them.
4. Keep encrypted off-host copies and test that recovery access does not depend solely on the failed mail server.

A mailbox filesystem copy does not restore account metadata. Replication also does not protect against a destructive change propagated to every replica.

Rehearse upgrades and recovery

Follow release-specific upgrade instructions in their documented order, including component changes and configuration migrations. Do not substitute an Enterprise migration guide for an open-source upgrade.

Restore into an isolated compatible system and verify authentication, old messages, aliases, controlled receipt/submission, and signing. Keep old queue data from delivering alongside the active server. Plan rollback using compatible backend/configuration backups rather than only downgrading one package. After maintenance inspect mail-flow logs and client access as well as service status; a running process can still have broken backend credentials.