Back up mox and verify a recoverable mailbox copy

Use mox’s backup facilities instead of assuming a live filesystem copy is consistent. A completed copy is not proof that account metadata and mailbox contents can be recovered together.

Capture and inspect the recovery set

1. Review mox backup and mox verifydata in the current command reference, including ownership, paths, and running-instance requirements.
2. Choose a protected destination with sufficient storage and keep an off-host encrypted copy.
3. Preserve the configuration, account/domain state, and required key/certificate material according to the release’s backup contract.
4. Validate the resulting data with the supported verification workflow and monitor job failures/backup age.

The command forms are mox backup <destination> and mox verifydata <data-directory>; confirm the exact release behavior before running them. These commands are not executed by this documentation.

Prove restoration in isolation

Restore a compatible backup on a non-public test host. Check ownership, mailbox counts/content, authentication, and client access without moving production DNS or letting the restored instance deliver old queued mail.

Before upgrading, read release notes and record a compatible data/configuration rollback point. Retain the old state until recovery tests pass; merely replacing the executable does not reverse every migration. Track pending outgoing work so restoring a backup and resending from the application cannot produce duplicate messages. A mailbox export can help portability but should not be confused with a full operational backup.