Plan WildDuck mail-suite backup and recovery
Recover authoritative database and attachment data with compatible SMTP integration state instead of backing up only stateless application containers.
Reviewed
WildDuck’s scalable application processes do not make mailbox data disposable. MongoDB and the selected attachment backend hold state; a full suite adds SMTP queue and integration configuration outside the IMAP process.
Inventory the recovery boundary
- Review architecture, storage, and upgrade requirements in the official docs.
- Back up authoritative MongoDB data using a consistent supported method, including the account/message metadata required by the release.
- Preserve the selected GridFS/S3 attachment data, service configuration, keys, and required integration credentials.
- Account for Redis/service state according to its role and for ZoneMTA’s outstanding outbound queue when that component is deployed.
Database replication is not a substitute for historical recovery from accidental deletion. A metadata backup without its referenced attachments may produce apparently present but unreadable messages.
Restore without competing with production
Rebuild a compatible isolated environment, restore the recovery set, and test account authentication, message/attachment retrieval, and configured SMTP integrations. Prevent the test suite from receiving production MX traffic or replaying old queued sends.
Before upgrading, read both WildDuck and dependent SMTP component notes. Confirm data migrations and rollback compatibility rather than assuming an old container will read new schemas. After maintenance inspect queue/log evidence, mailbox access, and stored attachments; a healthy API endpoint alone does not prove complete recovery.