How to Email a MySQL Database Backup Automatically (September 2026 Guide)

You can email a MySQL database backup automatically by running a script that calls mysqldump, compresses the output with gzip, attaches it to a message via mutt, mailx, or PHPMailer, and triggers the script on a schedule with cron on Linux or Task Scheduler on Windows. In this guide I walk you through the exact scripts, the credential file that keeps your password out of ps, the retention policy that keeps your disk from filling up, and the troubleshooting steps that fix the silent failures I have personally debugged for clients over the last decade.

By the end you will have a copy-paste shell script, a working cron entry, and a clear understanding of when email is the right delivery channel and when you should swap it for S3 or another cloud target.

Quick Steps: Email a MySQL Backup Automatically

If you just want the working pipeline right now, here are the five steps I use on every new server. I will explain each one in detail below.

1. Create a credentials file at ~/.my.cnf with your MySQL username and password, then chmod 600 it.
2. Write a shell script that runs mysqldump --single-transaction --all-databases | mutt -a - -s "Daily backup" to your address.
3. Test the script manually and confirm the email lands in your inbox with the .sql.gz attachment.
4. Add a cron line such as 0 2 * * * /home/you/scripts/mysql-email-backup.sh to run it nightly at 02:00.
5. Verify the next morning that cron actually ran (check /var/log/syslog or your MAILTO inbox) and restore the dump locally to confirm it is not corrupt.

One-liner preview of the core command:

mysqldump --single-transaction --all-databases | gzip | mutt -a - -s "MySQL backup $(date +%F)" [email protected]

What Is an Automated MySQL Email Backup and Why Set One Up

An automated MySQL email backup is a script that runs mysqldump (or a similar tool) on a schedule, dumps your database to a .sql file, compresses it, and emails the file to you so you never have to remember to back up manually. The scheduler is cron, systemd timers, or Task Scheduler; the mailer is usually mutt, mailx, sendmail, or PHPMailer; and the cadence is most commonly once per day.

Manual backups fail for the same reason every time: nobody remembers. I have walked into small businesses whose last backup was six months old because the founder went on vacation and the reminder email was lost in a spam filter. An automated pipeline removes the human from the loop and produces a verifiable artifact: the email in your inbox is itself proof that the script ran.

Email is also a free off-site copy. A dump sitting on the same disk as the database is useless when the disk dies. A dump sitting in your Gmail or Outlook inbox survives the same hardware failure. That said, email has size limits (Gmail caps attachments at 25 MB, Outlook at 20 MB) and a real security cost (a plaintext database dump contains every customer record, every password hash, every API key). I cover both risks in detail later in this guide.

Prerequisites Before You Start

Before you write a single line of script, confirm four things are in place. I have watched each of these silently break a backup pipeline.

• mysqldump is installed and on PATH. On Debian/Ubuntu run apt install mysql-client; on RHEL/CentOS run dnf install mysql; on macOS with Homebrew run brew install mysql-client. Test with mysqldump --version.
• A working mail transport. On a VPS this usually means a configured sendmail or Postfix with a smart relay. On a shared host (cPanel/Plesk) this is already provided. On a local laptop, you will need an SMTP relay pointed at Gmail or another provider.
• A scheduled-job tool. Linux uses cron or systemd timers; Windows uses Task Scheduler; macOS uses launchd. Cron is the most common choice and the one I demonstrate below.
• Outbound disk space for at least one full dump. A 500 MB database needs at least 500 MB free before compression, and ideally double that to keep one rolled copy while the new one writes.

If you are on cPanel or Plesk, also confirm that your host allows long-running cron jobs and outbound SMTP. Some shared hosts throttle or block cron mail entirely.

Linux Method: Shell Script with cron

The Linux pipeline is the simplest and most reliable. Here is the complete script I deploy for clients on Ubuntu 22.04 and Debian 12.

Create a directory for the script and the credentials file:

mkdir -p ~/scripts ~/backups
chmod 700 ~/scripts ~/backups

Open your editor on ~/scripts/mysql-email-backup.sh and paste this. Replace [email protected] with your real address.

#!/usr/bin/env bash
# Email a MySQL database backup automatically.
# Requires: mysqldump, gzip, mutt, ~/.my.cnf with 0600 perms.

set -euo pipefail

DB_NAME="${DB_NAME:-all}"
BACKUP_DIR="$HOME/backups"
DATE="$(date +%Y-%m-%d_%H%M%S)"
LOG="$BACKUP_DIR/backup-$DATE.log"
DUMP="$BACKUP_DIR/backup-$DATE.sql.gz"
EMAIL="[email protected]"

# Ensure defaults file exists and is locked down.
umask 077
[ -f "$HOME/.my.cnf" ] || { echo "Missing $HOME/.my.cnf" >&2; exit 1; }

# Dump (uses credentials from ~/.my.cnf).
mysqldump --single-transaction --quick --routines --triggers 
  --events --hex-blob "$DB_NAME" | gzip -9 > "$DUMP"

# Capture pipeline exit code (gzip fails if mysqldump produced empty input).
if [ ! -s "$DUMP" ]; then
  echo "Backup file is empty" | mutt -s "MySQL backup FAILED $DATE" "$EMAIL"
  exit 2
fi

# Email as attachment.
echo "MySQL backup for $DB_NAME on $(date). Attached." 
  | mutt -a "$DUMP" -s "MySQL backup $DATE" "$EMAIL"

# Retention: delete dumps older than 14 days.
find "$BACKUP_DIR" -maxdepth 1 -type f -name 'backup-*.sql.gz' -mtime +14 -delete
find "$BACKUP_DIR" -maxdepth 1 -type f -name 'backup-*.log'    -mtime +14 -delete

echo "OK $(date -Iseconds) $DUMP $(stat -c%s "$DUMP") bytes" >> "$LOG"

Make it executable and test it manually before you wire it into cron:

chmod 700 ~/scripts/mysql-email-backup.sh
~/scripts/mysql-email-backup.sh

You should receive an email within a minute with a .sql.gz attachment. If the attachment is missing, jump to the troubleshooting section below.

Now wire it into cron. Open your crontab with crontab -e and add this line to run every night at 02:15:

MAILTO=""
15 2 * * * /home/you/scripts/mysql-email-backup.sh >> /home/you/backups/cron.log 2>&1

I set MAILTO="" to disable cron’s own mail-on-output behavior because the script handles its own mail. If you want cron to email you any unexpected stderr, leave MAILTO pointed at your address and remove the redirect.

How to Send Email from cron with mutt, mailx, or sendmail

Three tools dominate the Unix mail-from-script landscape. Each has trade-offs, and the wrong choice is the difference between a working pipeline and silent failure.

mutt is the easiest for attachments. Install with apt install mutt. The command syntax is what I showed above:

mysqldump mydb | gzip | mutt -a - -s "Daily backup" [email protected]

The dash after -a tells mutt to read the attachment from stdin. mutt reads SMTP credentials from ~/.muttrc, which means you can keep authentication in one file with chmod 600.

mailx (the Heirloom or bsd-mailx variant) supports attachments via -a but the syntax is fussier and many distros ship a stripped-down mailx that does not handle attachments at all. If man mailx on your system shows no -a flag, install bsd-mailx or heirloom-mailx.

sendmail is the lowest level option. You generate the entire MIME message yourself with uuencode, which is fragile and rarely worth the effort for modern setups. I only reach for sendmail when mutt and mailx are both unavailable, which on modern distros is essentially never.

If you want a fully PHP-driven pipeline instead of shell, drop PHPMailer into the script. PHPMailer handles SMTP auth (including Gmail’s App Passwords and OAuth2) out of the box and supports attachments of arbitrary size. The trade-off is a larger dependency footprint and the need to keep the PHPMailer vendor directory up to date.

Compressing and Encrypting the MySQL Dump

An uncompressed SQL dump is roughly the size of your database on disk. A 1 GB MySQL database produces a 1 GB text file. Compressing with gzip typically shrinks that by 70 to 85 percent, which is the difference between a 1 GB attachment Gmail refuses and a 200 MB attachment it still refuses (and yes, 200 MB is over the cap; I will get to that).

gzip -9 is the maximum compression level and worth the extra CPU on a nightly job. If you want even smaller files, swap gzip for xz or lzma; the gehrcke.de reference script in the SERP does exactly this and consistently produces files 10 to 15 percent smaller than gzip.

For sensitive databases, encrypt before emailing. gpg --symmetric --cipher-algo AES256 backup.sql.gz prompts for a passphrase and writes backup.sql.gz.gpg. You then email the encrypted file and store the passphrase in your password manager. Without the passphrase the attachment is useless to anyone who intercepts the email, which is the single biggest argument for this step.

Skip encryption only if the database contains no real customer data, no credentials, and no PII. For any production system, treat the dump as a secret.

Securing Database Credentials in Your Backup Script

The single most common mistake I see in backup scripts is the password on the command line. mysqldump -u root -pMyVerySecretPassword mydb exposes the password to every other user on the box via ps aux and /proc. On a shared host, that means every other tenant on the machine can read it for the entire duration of the dump.

The fix is a MySQL client options file at ~/.my.cnf with permissions 600:

[client]
user=backup_user
password=your_password_here
host=localhost

chmod 600 ~/.my.cnf

When mysqldump is invoked with no -u or -p flags, it reads ~/.my.cnf automatically. The password never appears in ps, never appears in shell history, and is readable only by the account that owns the file.

For scripts run by accounts other than root, use the --defaults-extra-file flag and point it at a file with permissions locked down even further:

mysqldump --defaults-extra-file=/etc/mysql/backup.cnf mydb

Create a dedicated MySQL user with read-only privileges on the databases you back up. GRANT SELECT, LOCK TABLES, SHOW VIEW, EVENT, TRIGGER ON mydb.* TO 'backup_user'@'localhost'; is a reasonable baseline. Never reuse your application’s MySQL account for backups; rotating its password would silently break the pipeline.

Windows Method: Batch File with Task Scheduler

Windows does not have cron. The equivalent is Task Scheduler, and the script type is a .bat file that calls mysqldump, pipes through 7z or PowerShell’s Compress-Archive, and sends via a small PowerShell helper using Send-MailMessage (deprecated) or the newer MailKit via a small helper.

Save this as C:Scriptsmysql-email-backup.bat:

@echo off
setlocal

set TS=%date:~10,4%-%date:~4,2%-%date:~7,2%_%time:~0,2%%time:~3,2%
set TS=%TS: =0%
set DUMP=C:Backupsbackup-%TS%.sql

"C:Program FilesMySQLMySQL Server 8.0binmysqldump.exe" ^
  --defaults-extra-file=C:Scriptsbackup.cnf ^
  --single-transaction --routines --triggers --events ^
  mydb > "%DUMP%"

if not exist "%DUMP%" (
  powershell -Command "Send-MailMessage -From '[email protected]' -To '[email protected]' -Subject 'MySQL backup FAILED %TS%' -Body 'Dump file missing' -SmtpServer 'smtp.yourdomain.com'"
  exit /b 2
)

"C:Program Files7-Zip7z.exe" a -tgzip -mx=9 "%DUMP%.gz" "%DUMP%"
del "%DUMP%"

powershell -Command ^
  "$msg = Get-Content 'C:Scriptsemail-template.txt' -Raw; ^
   Send-MailMessage -From '[email protected]' -To '[email protected]' ^
   -Subject 'MySQL backup %TS%' -Body $msg ^
   -Attachments '%DUMP%.gz' ^
   -SmtpServer 'smtp.yourdomain.com' -Port 587 ^
   -UseSsl -Credential (Get-Credential)"

The companion credential file at C:Scriptsbackup.cnf:

[client]
user=backup_user
password=your_password_here
host=localhost

Lock the directory down so only your account and the SYSTEM account can read it. On Windows, that means right-click the folder, Properties, Security, and remove inherited permissions from everyone except Administrators and your backup service account.

Now schedule it. Open Task Scheduler (taskschd.msc), click Create Basic Task, name it MySQL Email Backup, set the trigger to Daily at 02:00, set the action to Start a Program, and browse to C:Scriptsmysql-email-backup.bat. Finish the wizard, then open the task’s Properties and check Run whether user is logged in or not and Run with highest privileges.

If you prefer PowerShell over batch, the entire script can be written in .ps1 with Start-Process mysqldump, Compress-Archive, and Send-MailMessage (or MailKit). The trade-off is that PowerShell scripts default to a restricted execution policy; you will need Set-ExecutionPolicy RemoteSigned for the running account.

cPanel and Plesk: Shared Hosting Cron Jobs

Shared hosting adds three constraints: you usually cannot install mutt, you do not have root access to /etc/my.cnf, and cron jobs run from a stripped PATH.

On cPanel, log in, open Cron Jobs, and set the schedule. For the command field, use the absolute path to mysqldump and call PHP’s mail or a wrapper script that does the work:

/usr/bin/mysqldump --defaults-extra-file=/home/youruser/.my.cnf --single-transaction youruser_dbname | /usr/bin/uuencode backup.sql | /usr/sbin/sendmail [email protected]

cPanel’s email route is the local sendmail binary, which on a properly configured cPanel server is already pointed at the hosting provider’s SMTP relay. You do not need to authenticate from cron.

On Plesk, the equivalent is Scheduled Tasks under Tools and Settings. Plesk exposes the same /usr/bin/mysqldump and the same sendmail wrapper, but the cron PATH often omits /usr/sbin. Prefix the command with the absolute path of every binary you call, the way I showed in the Linux section above. The most common reason a Plesk cron job “fails silently” is exactly this: the script cannot find mysqldump or mutt because cron has a different PATH.

If you cannot install mutt on a shared host, fall back to PHP. A small PHP wrapper that calls mysqldump via shell_exec, writes to a temp file, and uses PHPMailer to send the attachment works on every cPanel and Plesk box I have ever used, and PHPMailer handles SMTP auth including Gmail App Passwords.

Mail Tools Compared: mutt vs mailx vs sendmail vs PHPMailer

Most tutorials pick one tool and run with it. I have used all four in production; here is the honest comparison.

mutt is a full terminal mail client repurposed for scripting. It handles attachments, multiple recipients, and inline HTML out of the box, and it reads SMTP credentials from ~/.muttrc. The downside is that it is a heavier install than mailx and pulls in ncurses as a transitive dependency.

mailx is the lighter option, but the attachment story depends entirely on which variant your distro ships. The GNU mailx on Debian does not support -a; the bsd-mailx on Debian does. On CentOS, mailx from the base repo does not, but nail does. Always check man mailx on your target system before assuming it will work.

sendmail is the lowest level and the most painful. You generate the entire MIME envelope yourself, which means you handle base64 encoding, boundary strings, and header folding by hand. I have not deployed a sendmail-from-script pipeline in a decade and do not recommend starting now.

PHPMailer is a PHP library, not a shell tool. It is the right choice when the rest of your pipeline is already PHP, or when you need OAuth2 SMTP auth against Gmail or Microsoft 365. The downside is that it cannot be called directly from cron; you need a PHP wrapper script.

For a brand-new Linux server, my default is mutt. For a Windows box, my default is PHPMailer via a small PowerShell wrapper. For cPanel shared hosting where mutt is unavailable, I fall back to a PHP wrapper around PHPMailer.

Logging, MAILTO, and Error Notifications in cron

The most common complaint about automated backups is that nobody notices when they fail. Cron’s MAILTO variable is the first line of defense: set [email protected] at the top of your crontab and cron will email you any stdout or stderr the script produces.

The catch is that MAILTO only fires when there is output. A script that runs mysqldump with stderr redirected to /dev/null and stdout piped to a file will produce no MAILTO email even when it fails. That is why my example script above calls mutt explicitly on failure, rather than relying on MAILTO to catch errors.

To detect success, use exit codes. Cron does not have a built-in success notifier, so the script itself has to send the email on success and send a different email on failure. The pattern I use:

mysqldump ... || { echo "Dump failed" | mutt -s "Backup FAILED $DATE" "$EMAIL"; exit 1; }

For richer logging, redirect all output to a logfile that gets rotated on the same 14-day cycle as the dumps. The example script in the Linux section writes one line per run to backup-$DATE.log with the size of the resulting file. That single number is enough to alert you when something has gone wrong: if a 500 MB database suddenly produces a 2 KB dump, you know the dump silently broke.

Backup Retention and Rotation

Backups you never delete will eventually fill your disk. Backups you delete too aggressively leave you exposed to silent corruption that you only notice when you need the file. The standard answer is 14 days of daily local copies plus an off-site copy that lives separately.

The find -mtime +14 -delete line in the example script above handles the local retention. For off-site, you have four common choices:

• Email. Free, automatic, but limited to 20 to 25 MB per attachment. Good for small databases, bad for anything over 100 MB uncompressed.
• S3, Backblaze B2, or another object store. Cheap, durable, and unbounded in size. Requires the aws CLI or rclone installed on the server.
• Dropbox or Google Drive. Easy to set up, but the Dropbox daemon on Linux is heavier than rclone.
• rsync to a second server. Cheap, fast, and you control the destination, but you are responsible for the destination’s uptime and security.

For a small business, the combination I deploy most often is daily local + weekly S3. The 3-2-1 rule (three copies, two media, one off-site) is the minimum you should aim for; the email pipeline gets you one copy on local disk and one copy in your inbox, which is technically 2-1-1. Add S3 and you hit 3-2-1.

Restoring and Verifying Your MySQL Backup

A backup you have never restored is not a backup. It is a hope. The GitLab 2017 incident, where a production database was lost during a planned replication failover, is the canonical cautionary tale: their backups existed, but the restore process had never been tested end to end.

Restore from a .sql.gz dump:

gunzip -c backup-2026-09-11_020015.sql.gz | mysql -u root -p mydb

Verify the row counts match:

mysql -u root -p -e "SELECT COUNT(*) FROM mydb.users;"
mysql -u root -p -e "SELECT COUNT(*) FROM mydb.orders;"

For a deeper integrity check, run CHECKSUM TABLE on the live database, restore the dump to a scratch database, and compare. Any row count or checksum that does not match is a sign the backup is corrupt and your script is silently producing garbage.

Schedule the restore test. The cheapest approach is a weekly cron job that restores the most recent dump to a scratch database, runs CHECKSUM TABLE on every table, and emails the result. If the checksums match, you have proof the pipeline is healthy. If they do not, you find out before the disaster, not during it.

When NOT to Email a MySQL Backup (Size Limits and Risks)

Email is the right delivery channel for small databases and the wrong one for large ones. Gmail caps attachments at 25 MB; Outlook at 20 MB; most ISPs in the same range. A 200 MB compressed dump cannot be emailed; it will be silently rejected at the SMTP level and you will receive nothing.

The workarounds are split-and-email (cut the dump into 20 MB pieces, email each, then concatenate on the receiving end), or swap to S3 entirely. Splitting is fiddly and error-prone; I recommend S3 or another cloud store as the default for any database over 100 MB.

The other risk is credential exposure. A plaintext SQL dump contains every customer record, every password hash (in many cases still in a reversible format), every API key, every session token. If the email account that receives the backup is compromised, the attacker gets the database. If the email is forwarded to a third-party service for archival, the dump lives on infrastructure you do not control.

Mitigations: encrypt the dump with gpg --symmetric before attaching, use a dedicated backup-only email account with two-factor auth, and never forward the backup mailbox to a third-party service. Treat the dump the same way you would treat a production database dump sitting on a USB stick: handle with care.

For databases containing regulated data (HIPAA, GDPR, PCI-DSS), email is almost certainly the wrong channel. Use an encrypted cloud store with audit logging, or a managed backup service that meets the relevant compliance framework.

Troubleshooting: Why Your cron Job Fails Silently

I have debugged enough broken backup pipelines to know that four issues account for 90 percent of failures. Here they are, in order of frequency.

1. Cron PATH is missing /usr/sbin or /usr/local/bin. Cron runs with a minimal PATH, usually /usr/bin:/bin. If mysqldump is in /usr/local/bin or mutt is in /usr/sbin, cron will report “command not found” while the script works perfectly in your interactive shell. Fix by either setting PATH in the crontab or using absolute paths in the script.

2. Empty dump files. The script “succeeds” and the email arrives, but the attached file is 0 bytes. The cause is almost always wrong credentials: mysqldump is silently failing to authenticate and writing nothing to stdout. Check the credential file, confirm the user has SELECT privileges, and add --verbose to mysqldump temporarily to see what is happening.

3. Attachment rejected by Gmail. The script runs, mutt sends the email, but no message reaches you. The cause is the attachment size cap. Check the size of the dump on disk with ls -lh; if it is over 20 MB, Gmail silently dropped the message. Switch to S3 or split-and-email.

4. Cron runs but no email and no log entry. Cron itself did not run the script. Most often the cause is wrong crontab syntax (a missing newline at the end of the file is a notorious silent killer). Test with crontab -l and confirm the line ends with a newline. If cron is not running at all, check systemctl status cron on systemd systems.

For each of these, the diagnostic is the same: run the script manually, confirm it works, then add it to cron and watch /var/log/syslog (or journalctl -u cron) for the next scheduled run. If the script works manually but fails in cron, the issue is environment (PATH, HOME, MAILTO). If the script fails in both, the issue is the script itself.

Alternatives Worth Considering

If scripting feels like too much, two managed options handle the same job without any code on your part. AutoMySQLBackup is a single shell script you drop into /etc/cron.daily; it dumps every database, rotates, compresses, and supports email via MAILTO. It has been around since 2002 and is still maintained.

phpMyBackupPro is a PHP-based web UI for scheduling MySQL backups. You install it once, configure the databases and the cron equivalent through the browser, and it produces emailed dumps the same way the script does. The trade-off is the web UI itself, which adds an attack surface that a plain cron script does not have.

For cloud-hosted MySQL (Amazon RDS, Google Cloud SQL, Azure Database for MySQL), you cannot run mysqldump on the host because you do not have filesystem access to the database server. The cloud provider’s snapshot feature is the right tool; if you want a SQL-format dump, run mysqldump from a separate EC2 instance or Cloud SQL proxy pointed at the managed database. Email of the dump from a managed database works the same way as on a self-hosted box; the size limits still apply.

Frequently Asked Questions

Conclusion

Emailing a MySQL database backup automatically is one of those tasks that takes an hour to set up the first time and saves you from a disaster that would otherwise take days to recover from. The core pipeline is short: mysqldump to a file, gzip to shrink it, mutt to attach it, cron to schedule it, and ~/.my.cnf to keep the password out of ps. Add a 14-day retention, a weekly restore test, and an honest look at the size limits of your email provider, and you have a backup you can actually trust.

Next step: copy the script in the Linux Method section above, swap in your real email and database name, run it manually, confirm the email lands, then wire it into cron. Tomorrow morning, check your inbox. If a dump is there, you are done.