Self-Hosted Email Disaster Recovery: Backup Strategies That Hold Up Under Pressure
Why Disaster Recovery for Self-Hosted Email Is Different
Self-hosted email disaster recovery starts with an uncomfortable truth: when your self-hosted mail server goes down, you have no one to call. There's no support escalation to a vendor operations team, no redundant infrastructure automatically picking up the load. Recovery is entirely your problem — which means the preparation for it has to be entirely yours too.
The good news is that a self-hosted mail server failure is recoverable with the right preparation. Failure modes are predictable, backups are yours to design, and with a documented runbook, a two-hour outage can become a 20-minute one. But none of that happens without deliberate planning before anything breaks.
Understanding What Can Go Wrong
Hardware and Disk Failure
The most common cause of mail data loss in self-hosted environments. Spinning disks fail without warning. SSDs die suddenly. A server running a mail store on a single disk with no RAID is one disk failure away from losing everything. Even with RAID, a controller failure or a simultaneous two-disk failure in a RAID 5 array can take out the entire array.
OS or Software Corruption
A failed package update, a corrupted configuration file, or an interrupted database write can prevent the mail server software from starting. Postfix, Dovecot, and similar systems are generally stable, but software issues happen — especially after OS upgrades or when dependencies shift unexpectedly.
VPS Provider Outage
If your mail server lives on a single VPS at a single provider in a single region, a datacenter event takes it offline. Network issues, hypervisor failures, and full datacenter outages — while rare — do happen. Self-hosting on a single VPS is single-region, single-provider, single-point-of-failure by definition.
Security Compromise
A compromised server may need to be taken offline, rebuilt from scratch, and restored from backup. If the backups are stored on the same compromised server, they may also be tainted or deliberately deleted. Proper disaster recovery assumes the worst-case scenario where the entire server environment is untrustworthy.
The Backup Architecture That Actually Works
Off-Site Backups, Rotated Daily
Backups that live on the same server — or even the same datacenter — aren't disaster recovery. They're convenience copies. A real backup strategy pushes data to a separate location every day: object storage in a different region, a secondary VPS at a different provider, or an off-premises backup system. Geographic separation matters when the primary site has a physical or network problem.
What to Back Up
For a mail server, the critical data to capture includes:
- Mail store: The directory where messages are stored (typically
/var/mailor your configured Maildir location) - Configuration files: Postfix, Dovecot, SpamAssassin, and any other service configs (typically under
/etc) - TLS certificates and private keys: Stored with appropriate access restrictions
- DNS zone files: If you're also self-hosting DNS
- User and account database: The authentication database for mailbox credentials
Testing Restores Regularly
A backup that has never been tested is a hypothesis, not a guarantee. Restore drills should happen quarterly — spin up a test instance, restore from the backup, and verify that mail can be received and sent correctly. The test reveals whether the backup process is actually capturing everything it needs to, including configuration state that's often overlooked.
Backup MX: Keeping Mail Flowing During Downtime
While your primary server is down, mail sent to your domain needs somewhere to go. Without a backup MX configured, sending servers will queue messages and retry for a limited window — typically 24–72 hours before giving up. If the outage exceeds that, you lose mail.
A backup MX accepts messages when the primary is unavailable and queues them for delivery once the primary comes back online. The backup MX should live at a different provider from the primary — otherwise a provider-level outage takes both down simultaneously. For more context on how MX record fallback works, see MailDog's guide on backup MX records.
The Recovery Runbook
A runbook is a documented procedure for recovering the mail server from various failure scenarios. It should exist in writing, be stored somewhere accessible when the server is down (not on the server itself), and cover at minimum:
- How to access the backup data and from where
- Steps to provision a replacement server or restore the existing one
- Order of service restoration: network connectivity first, then DNS, then mail software, then mail store restore
- How to verify the server is functioning correctly after recovery
- Who to notify during and after an outage
The runbook should be tested by someone other than the person who wrote it. If only one person in your organization can execute the recovery procedure, you have a human single point of failure that no amount of backup infrastructure eliminates.
When Self-Hosting Is No Longer Worth It
If maintaining backups, testing restores, configuring backup MX, and writing runbooks sounds like too much overhead for your organization, that's a reasonable conclusion. Managed email hosting transfers the disaster recovery burden to the provider — who has full-time infrastructure staff, redundant systems, and defined SLAs for uptime.
For many organizations, the total cost of self-hosting — including time spent on maintenance and the risk cost of potential outages — exceeds managed hosting fees. MailDog's hosted email service is worth comparing against your current self-hosting costs. See the pricing page for context, or contact the team to discuss migration options if you're ready to move away from self-hosting.
