PowerMTA Configuration Backup and Disaster Recovery Planning

What Needs to Be Backed Up in PowerMTA

A PowerMTA disaster recovery plan must cover four categories of data: configuration files (the primary operational asset), DKIM private keys (non-recoverable if lost), license files (requires vendor re-issue), and accounting logs (deliverability history and compliance records). The spool directory — containing queued messages — is typically not backed up due to its size and transient nature; messages in the spool are re-injected from the sending application if the server is rebuilt.

Automated Configuration Backup

#!/bin/bash
# /usr/local/bin/backup_pmta.sh — run daily via cron
BACKUP_DIR="/var/backups/pmta"
REMOTE="backup@backup-server.yourdomain.com:/backups/pmta"
DATE=$(date +%Y%m%d)

mkdir -p $BACKUP_DIR/$DATE

# Backup configuration
cp -r /etc/pmta/ $BACKUP_DIR/$DATE/config/

# Backup DKIM keys (most critical)
cp -r /etc/pmta/dkim/ $BACKUP_DIR/$DATE/dkim/

# Backup license
cp /etc/pmta/license $BACKUP_DIR/$DATE/

# Compress
tar -czf $BACKUP_DIR/pmta-config-$DATE.tar.gz -C $BACKUP_DIR $DATE/
rm -rf $BACKUP_DIR/$DATE

# Sync to remote backup (rsync over SSH)
rsync -az $BACKUP_DIR/pmta-config-$DATE.tar.gz $REMOTE/

# Keep 30 days locally
find $BACKUP_DIR -name "pmta-config-*.tar.gz" -mtime +30 -delete

echo "PowerMTA backup complete: pmta-config-$DATE.tar.gz"

# Cron: 0 3 * * * /usr/local/bin/backup_pmta.sh >> /var/log/pmta-backup.log 2>&1

Git-Based Configuration Version Control

For teams with multiple operators, storing PowerMTA configuration in a Git repository provides version history, change attribution, and rollback capability. Every configuration change is committed with a message explaining the reason, creating an auditable history of infrastructure decisions.

# Initialize Git repo for PowerMTA config
cd /etc/pmta
git init
git add config domains/ *.conf
git commit -m "Initial PowerMTA configuration"

# After every config change:
git add -A
git commit -m "Increase Gmail max-smtp-out from 6 to 8 — IP now HIGH reputation"

# Push to remote (private repo only — config contains sensitive data)
git remote add origin git@github.com:yourorg/pmta-config.git
git push -u origin main

# .gitignore — exclude sensitive files from version control
cat > .gitignore << EOF
license
dkim/*.private
dkim/*.key
EOF
# DKIM private keys must NEVER be in version control

Disaster Recovery Procedure

# Full PowerMTA server rebuild from backup:

# Step 1: Provision new server with same OS version
# Step 2: Install PowerMTA RPM
rpm -ivh /tmp/powermta-6.x.x-1.el7.x86_64.rpm

# Step 3: Restore configuration from backup
tar -xzf pmta-config-YYYYMMDD.tar.gz -C /tmp/
cp -r /tmp/YYYYMMDD/config/* /etc/pmta/

# Step 4: Restore DKIM keys
cp /tmp/YYYYMMDD/dkim/* /etc/pmta/dkim/
chmod 640 /etc/pmta/dkim/*.private
chown root:pmta /etc/pmta/dkim/*.private

# Step 5: Request new license for new server MAC address
ip link show eth0 | grep "link/ether"
# Send MAC address to Port25 for new license

# Step 6: Start service and verify
systemctl start pmta
pmta show status
pmta check-dkim --domain=yourdomain.com --selector=s1

RTO/RPO Targets for Email Infrastructure

Disaster Recovery Testing

A backup procedure that has never been tested is not a backup procedure. Quarterly, rebuild PowerMTA from backup on a test server: restore config files, DKIM keys, verify license loads, confirm DKIM signing produces valid signatures. Document the expected rebuild time — this is your RTO. If rebuild takes 4 hours, your disaster response plan must account for that timeline. Test annually at minimum, quarterly for production-critical environments.

Accounting Log Analysis for This Configuration

Monitor this configuration area through the PowerMTA accounting log's dsnDiag field. Filter accounting records for the specific ISP domains affected by this configuration and group dsnDiag responses by first 60 characters to identify the dominant error patterns. A deferral rate above 5% at any single ISP warrants investigation; above 15% requires immediate volume reduction and configuration review.

The dlvSourceIp field in the accounting log enables per-IP analysis within this configuration context. Comparing per-IP deferral rates identifies whether a configuration issue affects all IPs in a pool uniformly (configuration problem) or just specific IPs (reputation or IP-specific problem). This distinction determines the correct remediation path.

Calibrating to Your Current Environment

The parameter values documented in this reference are appropriate for established, warmed IPs with HIGH reputation at the target ISP. New or warming IPs, and IPs with MEDIUM or LOW reputation, require more conservative values. Move up incrementally as reputation signals confirm the infrastructure can sustain additional throughput. Review ISP-specific configuration monthly — Postmaster Tools reputation tier changes and SNDS status changes are the primary triggers.

Production Deployment Summary

Implementing this PowerMTA configuration correctly in production requires testing the specific parameter values against your actual IP reputation history, ISP distribution, and sending volume. The values documented here represent proven starting points, not fixed constants — your optimal configuration may differ based on your infrastructure's operational history.

After applying any configuration change, monitor the accounting log for the first 2-4 hours to verify the change produced the expected effect on deferral rates. A configuration change that was expected to reduce deferrals but shows no change (or increased deferrals) indicates either: the change addressed the wrong variable, or there is a confounding factor that needs investigation before continuing.

The Cloud Server for Email infrastructure team manages PowerMTA environments daily, applying the configuration principles documented in this reference series across clients with varied volume levels, ISP distributions, and reputation histories. Contact us at infrastructure@cloudserverforemail.com for a technical assessment of your specific PowerMTA configuration requirements.