Backup, Disaster Recovery (DR), and Multi-Site Deployment Strategy for an Enterprise Mail System

Posted on by Rico

Mail Server Series — Part 18

In Parts 1–17 of this series, we built a complete, enterprise-grade mail platform, including:

  • Postfix SMTP
  • Dovecot IMAP/LMTP
  • Amavis + ClamAV + SpamAssassin
  • SQL Bayes + TxRep reputation
  • Piler email archiving
  • Manticore full-text search (Chinese-enabled)
  • Roundcube Webmail
  • Docker-based deployment
  • HTTPS reverse proxy
  • DKIM / SPF / DMARC

However, no production-level mail system is complete without the final and most critical component:

Backup • Disaster Recovery • Business Continuity

This article provides a full enterprise-level blueprint for:

  • What to back up
  • Backup frequency and recommended strategies
  • How to rebuild the entire mail system after a disaster
  • How to design off-site DR and multi-site failover

1. Why Backup and DR Are Critical for a Mail System

Email contains a company’s most important communication records:

  • Legal and regulatory evidence
  • Supplier and customer communication
  • Financial documentation
  • High-risk entry point for attackers

If your mail system is damaged, corrupted, or lost:

  • Legal evidence may be gone
  • Business operations are disrupted
  • No access to historical communication
  • High compliance and audit risk

Therefore, any enterprise mail system must include:

✔ Robust backups
✔ Clear DR procedures
✔ Off-site redundancy
✔ Recoverability verification

2. Full Backup Checklist (8 Mission-Critical Items)

Your mail system is composed of multiple integrated services.
A complete backup must include all the following components.

2.1 Postfix (SMTP)

Backup:

  • /etc/postfix
  • /etc/postfix/sql/*.cf
  • tls_sni.lmdb
  • transport.lmdb
  • /var/log/postfix/*

❗ Do NOT back up /var/spool/postfix queue.
During DR, external servers will re-queue and re-deliver messages.

2.2 Dovecot (IMAP/LMTP/Sieve)

This is the most important part of the entire system.

Backup:

  • /etc/dovecot/*
  • /var/vmail/* ← ALL USER MAILBOXES
  • Sieve rules /etc/dovecot/sieve/*

📌 /var/vmail is the one directory that must NEVER be lost.

2.3 MariaDB (PostfixAdmin / Bayes / Piler)

Databases to back up:

DatabasePurpose
postfixDomains, mailboxes, aliases
sa40Bayes + TxRep
pilerPiler metadata, permissions, notes

Daily backup command:

mysqldump --single-transaction --routines --triggers --databases postfix sa40 piler > backup.sql

2.4 Piler Email Archive

Piler stores every incoming/outgoing email for compliance.

Backup:

  • /var/piler/store ← ALL archived emails
  • /etc/piler/*
  • piler.pem (decryption key – must be backed up!)

2.5 Manticore Search

Manticore is used for full-text search.

Backup:

  • /var/lib/manticore

However, indexes (RT tables) can be reconstructed via SQL schema.
Optional: only back up the data directory if data volume is small.

2.6 Roundcube

Backup:

  • /var/roundcube/config
  • /var/roundcube/db (SQLite)

Webmail is easy to rebuild, low risk.

2.7 SSL / Let’s Encrypt Certificates

Backup:

  • /etc/letsencrypt/*

2.8 All Docker Deployment Files

Backup:

  • docker-compose.yaml
  • Dockerfiles of all services
  • Startup shell scripts

These are required for DR to rebuild all containers.

3. Recommended Backup Strategy (Enterprise 3-1-2 Model)

We recommend:

✔ 3-1-2 Backup Model

LevelDescription
3 copiesOriginal + local backup + remote backup
1 off-sitePhysically separate location
2 technologiesExample: rsync + S3 backup

This protects against hardware failure, ransomware, and catastrophic events.

4. Backup Frequency Plan (Daily / Weekly / Monthly)

4.1 Daily Backup

ItemMethod
MariaDBmysqldump
/var/vmailrsync incremental
Piler storersync incremental
Dovecot / Postfix configfile-level backup

4.2 Weekly Backup

  • Full /var/vmail backup
  • Full Piler store backup
  • ZFS/Btrfs snapshot (if supported)

4.3 Monthly Backup

  • Replicate entire backup set to off-site storage
  • DR recovery test (simulate restoring data)

5. Complete Disaster Recovery (DR) Procedures

If your main server crashes or the entire datacenter becomes unavailable, follow this DR process.

5.1 Step 1 — Create a New Server

Install:

  • Ubuntu 24.04 LTS
  • Docker + Docker Compose
  • Correct firewall rules for SMTP/IMAP

5.2 Step 2 — Restore Docker Directories

Restore backup of:

/opt/docker/mail/postfix
/opt/docker/mail/dovecot
/opt/docker/mail/piler
/opt/docker/mail/manticore
/opt/docker/mail/roundcube

5.3 Step 3 — Restore MariaDB

mysql < backup.sql

5.4 Step 4 — Restore User Mailboxes

rsync -av /backup/vmail/ /opt/docker/mail/dovecot/usermail/

5.5 Step 5 — Restore Piler Archive

rsync -av /backup/piler_store/ /opt/docker/mail/piler/piler_store/

5.6 Step 6 — Recreate Manticore Indexes

mysql -h manticore -P 9306 < manticore_piler_table.sql

Manticore does not strictly require backup—indexes can be rebuilt.

5.7 Step 7 — Start All Services

In proper order:

docker compose up -d maildb
docker compose up -d manticore
docker compose up -d piler
docker compose up -d postfix
docker compose up -d dovecot
docker compose up -d spamassassin
docker compose up -d webmail

5.8 Step 8 — Run Functional Tests

  • SMTP delivery test (swaks)
  • IMAP login test
  • DKIM/SPF/DMARC validation
  • SpamAssassin training test
  • Piler archive search test

6. Designing a Multi-Site DR Architecture (Advanced)

For higher reliability:

6.1 Active/Passive Dual-Site Setup

  • Site A: primary
  • Site B: warm standby

Synchronization:

  • MariaDB replication
  • vmail rsync (every 5 minutes)
  • Piler store incremental sync

6.2 Cloud Object Storage (S3 Remote Backup)

Use:

  • AWS S3
  • Backblaze B2
  • MinIO private cloud

6.3 Manticore DR Simplification

Index does not need real-time sync.
Piler messages + SQL metadata = fully recoverable.

7. Recommended Automation Scripts

  • Automated MariaDB nightly dump
  • Incremental rsync for vmail
  • Piler incremental backup
  • Encrypted backup bundles
  • Upload to S3/NAS scripts
  • N8N / Ansible automation

8. Summary

After implementing Part 18, your mail system now achieves:

✔ Fully protected

✔ Recoverable

✔ Audit-ready

✔ Multi-location failover

✔ Enterprise-grade business continuity

The entire system now meets:

  • Internal controls
  • Corporate governance
  • Security compliance
  • Legal retention requirements
  • Business continuity (BCP) standards