Backups of a clustered setup?

Questions
1

Your question

What backup strategies are others using for their stalwart clustered setups?

And have you done a restore of that setup incase of failure(s)?

My “failure/recovery” requirements would be to:
(a) when I need to move from one VM hosting provider/site to another
(b) rollback in case of corruption/ransomware attack.
(c) restoring a specific user’s mailbox incase of (lets say PEBCAK) issues

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

2

Here is a practical breakdown of backup options for a clustered Stalwart setup, covering all three of your failure scenarios.

Configuration backup (covers scenario a and b)

The primary tool for this is stalwart-cli snapshot. It walks the live server and exports all configuration objects (accounts, domains, DKIM signatures, TLS certs, system settings, blob/data/search store config, etc.) as an NDJSON plan that can be re-applied to a fresh server with stalwart-cli apply. A typical invocation:

stalwart-cli snapshot \
    Tenant Domain Directory DkimSignature AcmeProvider Certificate DnsServer Role \
    Account \
    SystemSettings DataRetention BlobStore InMemoryStore SearchStore \
    --allow-unresolved PublicKey \
    --output "backup-$(date +%Y-%m-%d).ndjson"

The docs explicitly list these use cases for snapshot plans:

  • Cross-environment migration (snapshot one server, apply to another – covers moving VM providers)
  • Disaster-recovery rehearsals (snapshot regularly, apply to a clean server to prove restorability – covers ransomware/corruption)
  • Configuration backup (commit to a private repo; secrets are automatically stripped, so you handle those separately via a secrets manager)

Reference: Exporting server state (snapshot)

Mail data backup (the actual emails, attachments, etc.)

This is the part that depends heavily on your storage backend choice. Stalwart separates storage into:

  • Data store (email metadata, mailbox structure, flags, calendars) – recommended backend for clusters: FoundationDB or PostgreSQL
  • Blob store (raw email content, attachments, Sieve scripts) – recommended for clusters: S3-compatible storage (MinIO, GarageHQ, AWS S3, Azure Blob)

Because these are standard, well-understood systems, their own backup/replication tooling applies:

  • FoundationDB has built-in backup and DR tools
  • PostgreSQL has pg_dump, streaming replication, point-in-time recovery (PITR)
  • S3/MinIO/GarageHQ support versioning and cross-site replication natively

For scenario b (ransomware/corruption), S3 object versioning or point-in-time restore on PostgreSQL/FoundationDB are the right mitigations at the data layer. The snapshot covers the config layer.

Reference: Storage backends for clustered deployments

Per-user mailbox recovery (scenario c)

Stalwart Enterprise has a built-in deleted item archive: emails deleted (even after expunge from Trash/Junk) are retained for a configurable period (archiveDeletedItemsFor on the DataRetention object, e.g. "30d"). Recovery is available through the WebUI (account view) or via the JMAP API/CLI (x:ArchivedItem/set). This is account-scoped, so admins can recover mail for any user.

For deeper per-user restores (e.g., restoring from a point-in-time backup of the data store), you would restore the underlying data store (PostgreSQL/FoundationDB) to that snapshot and use IMAP (imapAppend permission) to re-inject messages, as there is no Stalwart-native per-user mailbox import tool documented.

Reference: Storage overview – Un-deleting emails

Summary: Use stalwart-cli snapshot for config-layer backup/migration, use your data/blob store’s native backup tools for mail data, and use the Enterprise archived-items feature for per-user PEBCAK recovery. The snapshot + S3 versioning combination covers all three of your stated failure scenarios cleanly.

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

3

Anybody else with their views/experiences?

4

There are two complementary layers. For the whole dataset (good for provider migration and for rolling back after corruption), the server-level export/import via stalwart --export and --import snapshots and restores the entire store. For granular per-mailbox backup and restore (your single-user case), Vandelay writes a self-contained SQLite archive per account, incrementally, and restores via its export command with --prune for an exact mirror and --dry-run to preview. Docs: Backup | Stalwart .

One caveat worth flagging: the Vandelay archives cover account data only, not server settings, access controls or provisioning, so back the config store up separately (plus a store export). For a cluster specifically there’s no dedicated backup doc, so the practical approach is to snapshot the shared data/blob stores at the storage layer (RocksDB/S3/DB) and keep a config-store copy; it’s worth a docs addition. What backing stores are you running (RocksDB vs an external DB/S3)? The storage-layer backup differs by backend.

5

The part case that (re)triggered this question for me is a migration I needed to do for a client from a remote that is a “cPanel” type, ie, they are suppose to give you a big file with the emails. I use supposed as the emphatic, as we can’t find that file yet on their backups. As the MSP, the client/tenant wants all their user emails/data proven backed up or archived from me too.