MySQL自动备份Shell脚本实战：从编写到定时执行的完整指南

目录

• 为什么需要自动备份脚本
• mysqldump 基础用法速查
• 完整备份脚本实战
• 接入 crontab 定时执行
• 数据恢复操作流程
• 生产环境最佳实践
• 总结

为什么需要自动备份脚本

数据库是网站的核心资产。一旦数据丢失，业务可能直接瘫痪。MySQL 官方提供的 mysqldump 是最常用的逻辑备份工具，但每次手动执行既费时又容易忘。一个靠谱的自动备份 Shell 脚本，能把这件事变成完全自动化的流程——每天定时跑，自动压缩，自动清理旧文件，你只需要定期检查备份是否正常即可。

这篇文章不打算讲太多理论，直接从实战出发：先搞懂 mysqldump 怎么用，再手把手写一个可上生产环境的备份脚本，最后把它接进 crontab 实现全自动运行。

mysqldump 基础用法速查

先过一遍最核心的几个参数，搞清楚它们分别解决什么问题。

基本语法

mysqldump -u用户名 -p密码 数据库名 > 备份文件.sql

常用参数

• -A 或 --all-databases：备份所有数据库
• -B 或 --databases db1 db2：备份指定多个数据库
• --single-transaction：对 InnoDB 引擎开启事务备份，不锁表
• --master-data=2：记录备份时的 binlog 位置，方便增量恢复
• -x 或 --lock-all-tables：锁全表（MyISAM 适用，会锁表）
• -t 或 --no-create-info：只备份数据，不备份表结构
• -d 或 --no-data：只备份表结构，不备份数据
• --hex-blob：将 BINARY/VARBINARY/BLOB 等字段用十六进制存储

对于生产环境，我建议用 --single-transaction 搭配 --master-data=2，既能保证数据一致性，又不会锁死业务。

完整备份脚本实战

下面这个脚本是生产环境中常用的备份方案：全量备份 + gzip 压缩 + 保留最近 N 天 + 远程同步。

脚本内容

#!/bin/bash

# ========== 配置区 ==========
DB_USER="root"
DB_PASS="your_password"
DB_HOST="localhost"
BACKUP_DIR="/data/backup/mysql"
REMOTE_USER="backup"
REMOTE_HOST="192.168.1.100"
REMOTE_DIR="/backup/mysql"
KEEP_DAYS=7
DATE=$(date +%Y%m%d_%H%M%S)
LOG_FILE="/var/log/mysql_backup.log"

# 记录日志函数
log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOG_FILE"
}

# ========== 开始备份 ==========
log "===== MySQL备份开始 ====="

mkdir -p "$BACKUP_DIR"

log "正在执行 mysqldump ..."
mysqldump -h"$DB_HOST" -u"$DB_USER" -p"$DB_PASS"     --single-transaction     --master-data=2     --hex-blob     --routines     --triggers     --events     --all-databases | gzip > "$BACKUP_DIR/mysql_backup_$DATE.sql.gz"

if [ $? -eq 0 ]; then
    BACKUP_SIZE=$(du -h "$BACKUP_DIR/mysql_backup_$DATE.sql.gz" | cut -f1)
    log "备份成功！文件大小: $BACKUP_SIZE"
else
    log "备份失败！请检查 mysqldump 执行结果！"
    exit 1
fi

log "正在清理超过 $KEEP_DAYS 天的旧备份 ..."
find "$BACKUP_DIR" -name "mysql_backup_*.sql.gz" -mtime +$KEEP_DAYS -delete
log "旧备份清理完成"
log "===== MySQL备份完成 ====="
echo "" >> "$LOG_FILE"

脚本说明

这个脚本每个部分各司其职：

• 配置区：数据库账号密码、本地备份目录、远程服务器信息、保留天数，全部集中在顶部方便修改。
• 日志函数：每次操作都写日志，方便出问题后回溯。
• 备份命令：使用 --single-transaction 保证 InnoDB 数据一致性；加了 --master-data=2 方便以后做增量恢复；--routines --triggers --events 把存储过程、触发器、事件计划一起备份，不遗漏。
• 过期清理：用 find -mtime +7 删除 7 天前的备份文件。
• 远程同步：用 rsync 把备份推送到另一台服务器，防止本地磁盘损坏导致备份全灭。注释掉了，需要的取消注释即可。

给脚本加执行权限

chmod +x /usr/local/bin/mysql_backup.sh

接入 crontab 定时执行

脚本写好了，接下来用 crontab 把它变成自动化任务。每天凌晨 3 点跑一次，是大多数业务比较合适的时间点——业务低峰，备份对生产影响最小。

# 打开 crontab 编辑器
crontab -e

# 添加定时任务（每天凌晨3点执行）
0 3 * * * /usr/local/bin/mysql_backup.sh >/dev/null 2>&1

补充几个常用的定时策略供参考：

• 0 3 * * *：每天凌晨 3 点
• 0 3 * * 0：每周日凌晨 3 点（周备份）
• 0 */6 * * *：每 6 小时一次

写 crontab 时有个容易踩的坑：% 百分号在 crontab 中有特殊含义，如果脚本里用了 date 命令带格式化参数（比如 date +%Y%m%d），需要用反斜杠转义或改用单引号包起来。这个问题我在之前的 crontab 环境变量 PATH 配置 文章里有更详细的说明。

数据恢复操作流程

备份的目的就是为了恢复。恢复操作比备份简单，但每一步都不能搞错。

从压缩备份恢复

# 方式一：gunzip 解压后导入
gunzip < mysql_backup_20260522_030000.sql.gz | mysql -u root -p

# 方式二：一行命令搞定（推荐）
zcat mysql_backup_20260522_030000.sql.gz | mysql -u root -p

恢复指定数据库

# 先创建数据库（如果不存在）
mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS mydb CHARACTER SET utf8mb4;"

# 然后导入
zcat mysql_backup_20260522_030000.sql.gz | mysql -u root -p mydb

基于 binlog 的增量恢复（进阶）

如果做了 --master-data=2 备份，备份文件里会有一行类似这样的记录：

-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=12345;

这是备份结束时的 binlog 位置。如果要在全量备份基础上继续恢复到某个时间点，只需要找到对应时间段的 binlog 文件，执行：

mysqlbinlog --stop-datetime="2026-05-22 12:00:00" mysql-bin.000001 | mysql -u root -p

生产环境最佳实践

光有备份脚本还不够，几个关键环节决定了备份体系是否真正可靠。

1. 备份验证不能省

备份文件存在不代表能用。每次备份完成后，最好自动验证压缩包是否完整：

# 验证 gzip 完整性
gunzip -t "$BACKUP_DIR/mysql_backup_$DATE.sql.gz"

# 验证 SQL 文件内容（非空，且有数据）
zcat "$BACKUP_DIR/mysql_backup_$DATE.sql.gz" | grep "INSERT INTO" | head -5

2. 敏感信息不要写在脚本里

数据库密码直接写在脚本里不安全。更好的做法是把密码写到 /etc/mysql/mysql_backup.cnf 文件中，用 chmod 600 限制权限，然后用 --defaults-file 读取：

# /etc/mysql/mysql_backup.cnf
[client]
user=root
password=your_password

# 脚本中这样调用
mysqldump --defaults-file=/etc/mysql/mysql_backup.cnf ...

3. 监控备份是否正常执行

脚本跑成功了，你也得知道。有几种常见方式：

• 日志文件检查：定时检查 /var/log/mysql_backup.log 是否有最近的记录。
• 备份大小监控：如果某天备份文件异常小（比如小于 1KB），立刻告警。
• 定时任务邮件通知：crontab 可以配置 MAILTO，脚本出错时自动发邮件。

# 在 crontab 中添加邮件通知
MAILTO=admin@youres.cn
0 3 * * * /usr/local/bin/mysql_backup.sh

4. 多机备份策略

本地磁盘故障是不可忽视的风险。推荐的做法是本地保留近期备份，远程服务器保留更长周期的归档：

• 本地：保留 7 天
• 远程：保留 30 天（可以用对象存储 OSS/COS，按量付费，成本很低）

# 使用 rclone 同步到云存储（以阿里云 OSS 为例）
rclone copy "$BACKUP_DIR/mysql_backup_$DATE.sql.gz" oss:my-bucket/mysql_backup/

总结

MySQL 自动备份体系的核心就三件事：

• 备份脚本：用 mysqldump 做逻辑备份，gzip 压缩，find 清理旧文件，关键参数一个不能少。
• 定时执行：接进 crontab，选业务低峰时段，让它自己跑不用管。
• 恢复验证：定期做恢复演练，确认备份文件真的能用，别等出事才发现备份是坏的。

脚本写好之后不是就完了。建议每个月至少做一次恢复演练，验证备份数据的完整性和可用性——这是数据安全最后一道防线。

---

相关文章：

• Linux定时任务crontab详解：从语法规则到实战案例的完整指南
• MySQL数据库优化教程：从慢查询到高性能的完整实战指南
• 服务器自动备份方案：rsync异地增量备份实战指南