Back up and restore chat servers

MEM treats backup and recovery as a product workflow, not as a collection of Docker commands.

Outcome

After following this section, you can:

• capture a recovery-ready backup from a managed Matrix + Element stack;
• inspect the backup in the Backup Catalog;
• export an off-host portable ZIP or import one from another MEM server;
• open a durable Restore Workspace;
• run an optional private test before production changes;
• perform the supported Standard Recreate workflow;
• verify the recovered public service and complete handover;
• preserve evidence when a restore is cancelled or fails.

Canonical recovery model

Live Runtime Stack
  → local capture or imported portable ZIP
  → Backup Catalog entry
  → Restore Workspace
  → optional private test
  → Standard Recreate
  → public verification
  → operator handover

The Backup Catalog is the only supported restore source. An uploaded ZIP validation ID is an ingestion and provenance reference. It is not a restore-session ID and must not be used as a Restore Workspace route.

Start here

1. Create and inspect a backup.
2. Understand the Backup Catalog.
3. Export a portable backup and store it away from the MEM host.
4. When recovery is required, start a Restore Workspace.
5. Prefer the private test before production recreate when time permits.
6. Review Standard Recreate, target claims, and verification and handover before executing.

Restore is not migration

Restore recreates a supported MEM stack from a native Backup Catalog payload while preserving the backed-up Matrix identity. Migration assesses and converts a different or legacy source environment. Read Restore or migrate? before using a backup to move between unlike installations.

[!IMPORTANT] A server backup does not replace user recovery keys or device key backup. MEM can restore server-side rooms, events, accounts, media, configuration, and identity material that was captured. It cannot recreate end-to-end encryption keys that users never preserved.