What to Include in a Mail Server Backup Mail DB Config Certs

Why a Complete Mail Server Backup Is Non-Negotiable

You’re not just backing up mail files. You’re protecting the entire system that keeps your emails flowing.

One expired SSL certificate, one corrupted database, one misconfigured mail server, and your inbox goes dark — not in minutes, but in hours or days.

What to include in a mail server backup mail db config certs? Everything. Not just the mail files, but the database, configuration files, and certificates. Without them, recovery is guesswork.

Key takeaways

• A complete backup must include the mail database, configuration files, and SSL certificates — not just mail files.
• Lost or expired SSL certificates can instantly break email delivery and access, even if all other data is intact.
• Without a full backup, recovering from hardware failure, ransomware, or accidental deletion is unreliable or impossible.

What to Include in a Mail Server Backup: The Core Components

You need to back up the mail database (like SQLite or Postgres), mail storage directories (Maildir or mbox), Postfix and Dovecot config files, SSL/TLS certificates and keys, user Sieve filter scripts, and any automation scripts handling backups. Skip these, and recovery will fail or data will be lost. Let’s walk through each.

Core Data and Configuration

• Mail database: include the database storing user accounts, mailbox states, and message metadata — typically SQLite, MySQL, or Postgres. A missing DB means lost user data and permissions.
• Mail storage directories: back up the actual mailbox files, whether they’re in /var/mail, /home/user/Maildir, or traditional mbox files. Without these, your messages vanish.
• Postfix configuration: include /etc/postfix/ files like main.cf and master.cf, and any virtual domain/user maps. This ensures send/receive settings aren’t lost.
• Dovecot configuration: back up /etc/dovecot/ and any custom user or domain config, including users.db or mailboxes.conf. This preserves login logic and mailbox access rules.

Security and Automation

• SSL/TLS certificates and private keys: include full certificate chains and private keys for all domains — even internal or custom CA-signed ones. Losing these breaks encryption and can break mail delivery.
• Sieve filter scripts: back up users’ .sieve files (usually in ~/.sieve) that define spam rules, sorting, and automatic replies. These aren’t stored in the DB, so they’re easily missed.
• Backup automation scripts and cron jobs: include the /etc/cron.d/ or /etc/systemd/system/ files that run your backups. If you don’t, you’ll lose the routine even if the data exists.

Industry practices like those in RFC 5322 (SMTP) and RFC 6154 (Sieve) ensure that backup integrity respects mail standards — so don’t just copy files; validate their structure.

A well-structured backup is not just about safety — it’s about control. With Unifiedesk’s self-hosted option, you manage all of this yourself, including the encryption and retention of your data, down to the key level. Deploy your own server, keep your data on your terms, and ensure every component — from the mail DB to your backup script — stays under your oversight.

What to Include in a Mail Server Backup: Unifiedesk-Specific Paths

You need to back up five key areas in a Unifiedesk setup: the encrypted mail data at /var/lib/unifiedesk/mail/data, configuration files in /etc/unifiedesk/ (including postconf, dovecot.conf, jmapd.conf), TLS certificates from /etc/unifiedesk/ssl/, shared mailbox and admin settings in /etc/unifiedesk/admin/, and the per-tenant SQLite3 databases at /var/lib/unifiedesk/db/. These are the only paths you need to include for a complete recovery. Let’s break down each.

Mail Data and Database Files

Your actual email messages, calendar events, and document content are stored in /var/lib/unifiedesk/mail/data—each user’s data is encrypted at rest with AES-256-GCM under a per-account key. This means the backup must preserve file structure exactly, even if you’re using a script or tool like rsync or borg. The database files at /var/lib/unifiedesk/db/ are SQLite3 files, one per tenant, and they are also encrypted at rest. If you ever restore, you’ll need these intact to maintain data consistency and integrity across mail, calendar, and drive.

Configuration and Certificates

Configuration files in /etc/unifiedesk/ control how Unifiedesk behaves: mail routing, user authentication, JMAP and IMAP settings, and access policies. Changes here affect authentication, delivery, and performance. These should be versioned separately—using a tool like git or etckeeper is a proven best practice for system stability. TLS certificates in /etc/unifiedesk/ssl/ are used for secure connections (IMAP, SMTP, JMAP). You’ll need both private keys and public certificates here. Remember, misconfigured or expired certificates cause client failures—and some email clients, like those following RFC 5246 (TLS 1.2), refuse to connect to insecure domains.

Shared mailboxes and domain-wide settings live in /etc/unifiedesk/admin/. This includes team rules, domain policies, and default behaviors. These files are crucial if you manage multiple teams or domains. Losing them means losing your organization's identity and policy configuration. You don’t have to back up user data repeatedly to restore this—just the config files and database.

For a full recovery, combine all five paths. Use scripts or tools trained in system-level backups—always test on a staging instance first. You can find more about privacy, data control, and enterprise-grade features at our self-hosting page or explore the full suite with mail, AI assistant, and contacts.

How to Verify Your Backup Includes Everything: A Test Process

Let’s get real: a backup is only useful if it can actually restore your mail server. To verify yours includes everything, stop Unifiedesk services, run a manual backup, confirm db, conf, ssl, and data files are present, extract to a test directory, restart services, and test mail delivery. Finally, simulate a full restore on a clean server to prove end-to-end recoverability. This process prevents surprise failures during a real outage.

Step-by-Step Verification

1. Stop Unifiedesk services: Run sudo systemctl stop unifiedesk-mail unifiedesk-jmap. This prevents active data changes during the backup, ensuring consistency. A live database written to mid-backup can lead to corruption or missing data.
2. Run a manual backup: Execute sudo /opt/unifiedesk/bin/backup.sh /mnt/backup/2026-04-05. This creates a full snapshot of your mail database, config files, certs, and user data. Unlike automated backups, this gives you control over timing and location.
3. Verify file counts: Use ls -la /mnt/backup/2026-04-05/ | grep -E 'db|conf|ssl|data' to ensure key components exist. Look for mail.db, config.json, ssl/, and user_data/. Missing any of these means your backup is incomplete.
4. Extract and test: Copy the backup to a test directory, then restart services: sudo systemctl start unifiedesk-mail unifiedesk-jmap. Check if mail delivery works via IMAP or JMAP. Use a test account to send and receive. If messages don’t flow, the backup is incomplete.
5. Simulate real recovery: On a new server with the same OS and Unifiedesk version, restore the backup and verify all components work end-to-end. This isn’t just a test—it’s a simulation of disaster recovery, one of the best practices recommended by the National Institute of Standards and Technology (NIST) in SP 800-34 Rev. 2.

Why This Matters

Backups without testing are just data storage, not resilience. Many admins assume their backup works—but only when the real failure happens do they discover critical files were missing. Testing ensures you actually have a working recovery path.

For teams using Unifiedesk in production, this process isn’t optional. It aligns with core principles of system integrity. If you’re managing your own mail server, you’re responsible for validation. If you’re using a hosted plan, you still benefit from understanding how backups work—especially with self-hosting options that put you in charge of your data.

Mail Backup Checklist for Postfix & Dovecot: Real Paths, Real Files

You need to back up Postfix’s /etc/postfix/main.cf and /etc/postfix/virtual_domains, Dovecot’s /etc/dovecot/dovecot.conf and /etc/dovecot/conf.d/10-ssl.conf, plus your mail storage at /var/mail/virtual/—all with proper ownership and permissions. Don't skip the certificates, DKIM keys, or mail location paths. Let’s break down exactly what’s required.

Config & Data File Locations

When backing up a self-hosted mail server, focus on the actual files that define your setup. You can’t restore mail or delivery without them. Here’s what to include:

Always sync your backup with chown mail:mail and chmod 700 on the maildir root. A missing or wrong owner breaks access. For automation, use a script that runs weekly with find and tar—and test restores. The RFC 6154 defines the Maildir format; it’s reliable and used by mail servers including Cyrus and Dovecot.

Need a complete, private workspace? Unifiedesk handles all this for you with end-to-end encryption and real-time backup controls—no need to manage Maildir paths or SSL files manually. Try Unifiedesk self-hosted to control your data from the ground up.

SSL/TLS Certificates: The Forgotten Backup Must-Include

You must back up your mail server’s full SSL/TLS certificate chain—public cert, CA bundle, and private key—because missing any part breaks encryption, causes delivery failures, and flags your messages as insecure. Without the private key, your server can’t decrypt inbound mail or authenticate outbound connections. And if the CA chain is missing, clients and other servers won’t trust your TLS handshake, especially in strict environments.

Why the Full Chain Matters

Mail servers use TLS to secure communication with clients and other servers. When your certificate or private key is missing from backup, even a reboot can break mail flow. The public certificate alone doesn't help—your server needs the private key to handle encrypted sessions. Meanwhile, the CA bundle ensures clients verify your identity properly. Without it, systems like Gmail or Microsoft 365 may mark your messages as untrusted or reject them outright.

Let’s be clear: backing up just the public certificate is like keeping a door key without the lock. It’s useless. You need the full chain—public cert, CA chain, and private key. For Unifiedesk, the private key lives at /etc/unifiedesk/ssl/private.key, with strict permissions set to 600 (readable only by root). Never skip this file.

Standardized Naming and Storage

Use consistent naming to avoid confusion in recovery: domain.tld.crt for the public certificate, domain.tld.bundle for the CA chain, and domain.tld.key for the private key. This pattern is widely recognized across systems, including those used by Posteo, Fastmail, and Infomaniak. It simplifies automation and reduces human error during restore.

For reference, RFC 5280 describes certificate structure and validation; you can learn more at IETF’s RFC 5280. The same principles apply whether you're running a hosted service or self-hosting via Unifiedesk’s on-premise option. If you run a business and use custom domains, proper backup of these certs is non-negotiable for continuity.

And yes, the AI assistant, calendar, drive, docs, and video meetings all rely on secure connections too. You don’t want your entire workspace down because a TLS backup was incomplete.

Back up the whole stack: certs, keys, and bundle. Name them clearly. Store them offline, encrypted, and test restores. It’s not glamorous—but it’s real. And it’s what keeps mail moving, private, and trusted.

How to Securely Store and Test Your Backup Files

You must encrypt backups using GPG or AES-256-GCM, store them offsite or on disconnected media, enable versioning in storage (S3, MinIO), and validate recoverability by restoring at least quarterly. Without testing, backups are just data with no value.

Encryption and Storage Location

• Always encrypt mail server backups using gpg or AES-256-GCM—never store in plaintext.
• Use isolated storage: offsite physical drives, air-gapped systems, or S3-compliant object storage like MinIO with versioning enabled.
• Rotate encryption keys periodically and store the keyring securely—preferably in a password manager or hardware security module (HSM).
• Never keep backups on the same server or network as production; a compromise should not expose both.

Validation and Restore Testing

• Test full restores at least every 90 days. A backup that can’t be restored is not a backup.
• Use a staging environment for validation—never restore directly onto production.
• Validate that all core data is intact: mailboxes, calendar entries, contacts, and drive files.
• Document the restore process in plain steps—this becomes your recovery SOP if an outage occurs.

According to the U.S. Cybersecurity and Infrastructure Security Agency (CISA), "backup testing is one of the most overlooked yet critical parts of a cyber resilience strategy." You can't defend what you can’t recover.

For self-hosted teams running Unifiedesk, consider using the self-hosted deployment, which includes full control over backups, encryption at rest, and per-account keys. Your data stays under your control—no external access, no shared infrastructure.

“The only thing worse than not having a backup is having one you can’t use.”

Automate parts of your process using scripts that run gpg --encrypt and aws s3 cp (or similar), but always test manually at least once a quarter. The automation is only as reliable as the last successful restore.

Automating Mail Server Backups: Use the Right Tools

You should include the mail database, configuration files, SSL/TLS certificates, and authentication keys in your mail server backup, using tools like rsync over SSH for reliable syncs, tar with gzip and exclude rules for safe bundling, and a wrapper script that stops services, backs up data, restarts services, and verifies logs. For Unifiedesk, use the built-in /opt/unifiedesk/bin/backup.sh script, which respects per-account encryption and ensures integrity.

Sync with rsync and Validate with Checksums

Use rsync over SSH to perform daily incremental backups to a secure offsite server. It’s efficient, only transfers changed blocks, and supports checksum validation to detect silent corruption. This is a standard practice in systems administration, commonly recommended by resources like the RFC 5497 on secure file transfer best practices. Always verify the transfer with checksums to ensure data matches exactly.

Bundling with tar and Protection via Excludes

Use tar --gzip --exclude to bundle configuration files, mail data directories, and certificates into compressed archives. Exclude temporary, log, or cache directories to reduce size and avoid backing up transient data. This approach is robust and widely trusted — for example, it’s a core technique in the Linux Kernel Mailing List documentation style guide for managing system state.

Next, wrap the entire process in a shell script. Let's say it stops the mail server, runs the backup, restarts the service, then checks logs for any failure. A single failure in the chain should stop the process. This prevents silent corruption and ensures you know immediately if a backup failed.

For Unifiedesk, you don’t need to invent this from scratch. The platform ships with /opt/unifiedesk/bin/backup.sh, a ready-made wrapper that stops the mail service, backs up data, restarts it, and logs each step. It handles encrypted per-account databases correctly, avoiding the risk of backing up decrypted data — a critical detail often missed in manual scripts.

Always test your backup recovery process. A backup that can’t be restored is useless. Use this same script in a test environment first, and verify mail services resume with no errors. You're not just backing up files; you’re preserving a working, encrypted state of your email ecosystem.

Once the automation is working, schedule it with cron. Run it daily, and keep multiple daily archives — but rotate them properly so you don’t run out of disk space. Consider copying the latest backup to a separate server or cloud storage for extra protection.

When you’re running Unifiedesk on your own server, take advantage of its built-in tooling. You’re not just a user — you’re a system operator. Use what’s already secure, verified, and tested. That’s how you keep your email private — by doing it right, not by hoping.

What’s Not Needed in a Mail Server Backup? Avoid These Common Mistakes

You don’t need to back up log files, cache directories, session data, or old config fragments—they’re temporary, rebuildable, and bloat your backup without adding recoverability. Most backup tools miss this, and you’ll only store noise. Let’s cut the clutter.

What to Skip When Backing Up Your Mail Server

• Log files like /var/log/maillog and /var/log/dovecot are temporary and can be regenerated by the mail server. They don’t contain essential data and grow quickly—backing them up is wasted space.
• Cache directories such as /var/cache/unifiedesk or /tmp are transient and serve only short-term performance benefits. They’re safely deleted on reboot and aren’t needed for recovery.
• Per-user session files and cookies—stored in /var/lib/unifiedesk/sessions or similar—are ephemeral. They don’t survive restarts and are recreated on login, so they add no value to backups.
• Old or commented-out config fragments in /etc/unifiedesk/conf.d/ or /etc/dovecot/conf.d/ are just noise. Only backup active, validated, and applied settings—unused or legacy config can confuse recovery efforts.
• Temporary files created by tools like postfix or dovecot in /var/spool should not be included. These are auto-managed and can be safely reinitialized.

Why These Mistakes Hurt Your Recovery

Backups that include transients slow down backup windows, increase restore time, and risk corruption if stale data is restored. As noted in RFC 5322, mail system design prioritizes stateless recovery—meaning you should be able to re-create behavior from configuration and data, not stored runtime artifacts.

Think about it: if your email server crashes and you restore from a backup full of logs and temp files, you’ll likely face a broken state. The real data—messages, users, keys—is already in the right place. What you’re backing up now is just overhead.

Instead, use a minimal, targeted backup strategy: only the database, active configs, and certificates. That’s all you need to restore your mail server quickly and reliably.

If you manage your own server, Unifiedesk’s self-hosted version gives you full control over what’s backed up, with clear separation between data, config, and transient files.

Why Self-Hosting Demand a Full Backup Strategy

You’re not just running mail—you’re running your own infrastructure. If something breaks, there’s no vendor support to fall back on. A single missing config, expired certificate, or misconfigured domain can kill your mail flow—even if your database is intact. That’s why backups must include every piece: mail databases, SSL certificates, Postfix and Dovecot configs, DNS records, and all domain-specific settings. Without this, recovery is guessing, not restoring.

The Reality of Self-Hosted Control

When you self-host, you own every bit of data and every decision. That means you’re also responsible for every failure. You can’t call your cloud provider’s support and ask them to “restore my custom domain settings.” They don’t back up your config files or TLS certs—they’re not your infrastructure. The moment you go self-hosted, you trade convenience for control—but control demands preparation.

What’s Actually in a Mail Server Configuration?

Postfix and Dovecot don’t keep everything in one place. Postfix relies on /etc/postfix/main.cf and /etc/postfix/master.cf for routing, TLS settings, and access rules. Dovecot uses /etc/dovecot/dovecot.conf for authentication, storage paths, and encryption. SSL certs live in /etc/ssl/certs/ or /etc/letsencrypt/. Even your domain-specific mail routing lives in separate files. If you miss one, your server may work—but fail silently on delivery.

And yes, an expired TLS certificate can block incoming mail entirely. That’s why your backup must include not just mail data, but also /etc/ssl directories, /etc/dovecot and /etc/postfix trees, and your DNS zone records. Without them, you can’t restore service, even if your maildb is perfect.

See how this scales? Misconfigurations are the #1 cause of email outages in self-hosted environments, according to RFC 5321, which outlines how MTAs validate sender and recipient domains. If your server’s domain config doesn’t align with your DNS, your mail gets rejected—even with a healthy database. This isn’t just theory; it’s how spam filters work.

Let’s say you backup only your mail database and forget the certs. You restore the DB, but incoming mail fails with “TLS handshake failed.” You’re stuck. You forgot that your smtpd_tls_certificate_file in Postfix points to a file that no longer exists. That’s the cost of partial backups.

To avoid this, your strategy must cover: maildb, config files, SSL certs, DNS records, and user credentials. Use a tool like borg or rsync with encrypted storage. Test restores monthly. And if you’re using a platform like Unifiedesk for self-hosting, you get built-in support for per-account encryption, JMAP sync, and consistent config management—making your backup strategy more reliable, not harder.

Conclusion: Backup Isn’t Optional—It’s Your Lifeline

A backup that omits configs, certificates, or database metadata fails your organization when you need it most. Without these, recovery is impossible—your mail server won’t start, your domains won’t authenticate, and your data becomes useless.

Your complete operational safety net includes every piece: messages, user accounts, configuration files, TLS certificates, and database schema. Skipping any one component turns your backup into a false promise.

For self-hosted deployments—especially with Unifiedesk—automate backups and test recovery quarterly. A well-documented, verified restore procedure is the difference between downtime and resilience.

Ready to put this into practice? Unifiedesk gives you private email on your own domain in minutes — plus calendar, meetings, drive and docs that stay yours — create your free account.

Frequently asked questions

What happens if I don’t back up my mail server SSL certificate?

Email clients and servers will reject your mail server as insecure. Delivery will fail or be flagged as risky, and you’ll lose inbound mail until the certificate is restored.

Can I restore mail from a backup without backing up the database?

No. Without the database, user permissions, mail metadata, and sieve filters are lost. You can restore file contents but not delivery logic, mailboxes, or user settings.

Is it safe to store backup files in the cloud?

Only if encrypted end-to-end before upload. Cloud providers can access unencrypted data—never store plaintext backups in AWS, Google Cloud, or Dropbox.

How often should I test my mail server backup?

At least once every 90 days. A backup that hasn’t been restored is unverified and unreliable.

Does Unifiedesk include backup tools out of the box?

Yes. Unifiedesk includes /opt/unifiedesk/bin/backup.sh for self-hosted instances, which handles encryption, data, config, and certificate bundles.

Why does Unifiedesk encrypt the database at rest?

To protect email and file content even if storage is physically compromised. Data is encrypted per-account with AES-256-GCM, and decryption requires the user's key.

Do I need to back up the mail storage separately from the database?

Yes. The database contains metadata; the mail storage contains the actual message bodies. Both must be backed up together to restore fully.

What if my backup includes old or unused config files?

It’s safe to include them, but keep backups clean. Use versioned directories and exclude test or temporary configs in production.

Can I use rsync alone for mail server backup?

Yes, with strict exclusions and checks. But use it with a full integrity verification script. Don’t trust sync alone to be complete.

What’s the biggest mistake in a mail server backup strategy?

Assuming that backing up file storage is enough. Without configs, certs, and database, the server is broken—even if the files exist.

How do I verify a backup contains Dovecot's sieve filters?

Check the backup for user-specific filter files in /var/mail/virtual/<user>/filters or /etc/dovecot/sieve/<user>.sieve.

Should I include system logs in my mail server backup?

No. Logs are temporary and can be recreated. They serve no recovery purpose and bloat backup size unnecessarily.