Linux下用crontab和mysqldump实现MySQL定时自动备份

Mason

发布时间：2026-09-20| 4人浏览过

原创

在Linux生产或日常运维环境中，要实现MySQL数据库的定时自动备份，标准且成熟的做法是由Linux自带的计划任务服务crontab按预定频率唤起自定义Shell脚本，脚本内部调用mysqldump逻辑导出SQL文本，配合gzip实时压缩并清理过期副本。本文将给出可落地的标准脚本、免交互认证配置、执行周期设置以及失败验证的具体流程。

自动备份的系统交互架构

要让整个流程全天候无人值守运行，系统各个模块之间的协作边界必须清晰。自动备份并非单纯的一行命令，而是由时间调度、权限凭证、数据导出压缩以及磁盘容量维护四个环节组成的闭环链路。

图 1：自动备份链路的核心模块与数据流转关系

在上述架构中，mysqldump属于逻辑备份工具，它通过连接数据库服务端，将数据库的结构与数据转换成一组SQL语句（如CREATE TABLE、INSERT）。因为生成的SQL是文本，结合gzip进行管道流式压缩可以极大节省磁盘开销。

第一步：配置MySQL免密码登录凭证

许多初学者习惯在脚本或crontab中直接写上密码参数，例如 mysqldump -u root -p123456。这种做法看似合理，因为能解决批处理脚本需要密码的问题；但在Linux下，其他本地普通用户通过执行 ps aux | grep mysqldump 就能在进程列表中直接看到明文密码。此外，MySQL客户端也会直接抛出 [Warning] Using a password on the command line interface can be insecure. 的警告。

正确的做法是使用MySQL官方提供的 mysql_config_editor 工具，将登录凭据加密保存在执行用户的家目录下的 .mylogin.cnf 文件中。

在终端中以运行备份脚本的系统用户身份执行以下命令（此处以配置本地登录为例）：

mysql_config_editor set --login-path=backup_client --host=localhost --user=backup_user --password

按回车后，系统会提示输入该数据库用户的密码。输入完毕后，会在当前用户的家目录生成 ~/.mylogin.cnf，权限自动限制为当前用户只读（600）。

测试该免密路径是否正常生效：

mysql --login-path=backup_client -e "SELECT VERSION();"

如果直接返回了MySQL版本号而未提示输入密码，说明凭证已经配置成功。后续执行 mysqldump 时，只需加上 --login-path=backup_client 参数即可完成身份校验。

第二步：编写标准化备份与轮转脚本

自动化脚本不仅需要执行导出操作，还要解决另外两个关键问题：一是环境变量缺失问题，crontab执行时加载的环境变量非常精简，必须在脚本内指定工具的绝对路径；二是磁盘保护问题，必须在每次备份完成后自动删除超出保留期限的文件。

创建一个脚本文件，例如存放在 /data/scripts/backup_mysql.sh：

#!/bin/bash
# ==========================================================
# 脚本名称: backup_mysql.sh
# 功能描述: 定时通过 mysqldump 备份指定数据库，压缩并清理过期历史
# ==========================================================

# 1. 明确定义环境变量与执行路径，避免 cron 无法定位二进制程序
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# 2. 基础参数定义
LOGIN_PATH="backup_client"
DB_NAME="production_db"
BACKUP_DIR="/data/backup/mysql"
DATE_STR=$(date +%Y%m%d_%H%M%S)
TARGET_FILE="${BACKUP_DIR}/${DB_NAME}_${DATE_STR}.sql.gz"
LOG_FILE="${BACKUP_DIR}/backup.log"
RETENTION_DAYS=7

# 3. 检查并创建归档目录
if [ ! -d "${BACKUP_DIR}" ]; then
    mkdir -p "${BACKUP_DIR}"
fi

echo "[$(date '+%Y-%m-%d %H:%M:%S')] 开始执行数据库 [${DB_NAME}] 备份..." >> "${LOG_FILE}"

# 4. 执行导出与管道压缩
# --single-transaction: 对 InnoDB 引擎表获得一致性快照，不产生全局读锁
# --quick: 强制 mysqldump 从服务器一行一行检索表中的行，而不是先缓存到内存
# --routines --triggers: 连同存储过程与触发器一同导出
mysqldump --login-path="${LOGIN_PATH}" \
          --single-transaction \
          --quick \
          --routines \
          --triggers \
          "${DB_NAME}" \vert{} gzip > "${TARGET_FILE}"

# 5. 校验执行状态（检查管道退出码）
# PIPESTATUS[0] 记录管道左侧 mysqldump 的返回值
EXIT_CODE=${PIPESTATUS[0]}

if [ ${EXIT_CODE} -eq 0 ] && [ -s "${TARGET_FILE}" ]; then
    FILE_SIZE=$(ls -lh "${TARGET_FILE}" | awk '{print $5}')
    echo "[$(date '+\%Y-\%m-\%d \%H:\%M:\%S')] 备份成功完成: ${TARGET_FILE} (大小: ${FILE_SIZE})" >> "${LOG_FILE}"
else
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] 错误: 备份异常中断，退出码: ${EXIT_CODE}" >> "${LOG_FILE}"
    # 如果导出中断产生空文件，则清理该残损文件
    rm -f "${TARGET_FILE}"
    exit 1
fi

# 6. 清理 N 天之前的陈旧压缩包
find "${BACKUP_DIR}" -name "${DB_NAME}_*.sql.gz" -type f -mtime +${RETENTION_DAYS} -exec rm -f {} \;
echo "[$(date '+%Y-%m-%d %H:%M:%S')] 已执行过期备份清理，保留期: ${RETENTION_DAYS} 天" >> "${LOG_FILE}"

保存脚本后，为其授予可执行权限：

chmod +x /data/scripts/backup_mysql.sh

关于 --single-transaction 的适用边界：
这个参数依靠 InnoDB 的多版本并发控制（MVCC）实现无锁导出，保障生产业务读写不受阻。如果你的数据库包含 MyISAM 引擎表，该参数将无法保障一致性，甚至仍可能产生表锁；对于包含非事务性引擎的旧库，需要在低峰期或维护窗口操作。

图 2：脚本执行的具体逻辑判断与控制链条

第三步：使用 crontab 配置计划任务

有了可独立正常运行的脚本后，最后一步就是将其挂载到操作系统的定时调度引擎中。

在Linux系统中输入以下命令编辑当前用户的计划任务表：

crontab -e

在打开的文件末尾添加一行定时指令：

0 2 * * * /bin/bash /data/scripts/backup_mysql.sh >/dev/null 2>&1

crontab 语法要素剖析

crontab 由五个时间通配字段加上具体的执行命令组成。很多人对这五个字段的顺序容易混淆，可通过下图准确确认具体设定：

图 3：crontab 定时规则各个位置的实际含义解析

在命令末尾加上 >/dev/null 2>&1 是为了避免任务执行时的标准输出产生系统内部邮件累积。我们在前面的Shell脚本中已经主动向 backup.log 文件写入了详细日志，因此可以安全地丢弃终端输出。

第四步：手动验证与常见陷阱排查

不要在配置好 crontab 后直接等待第二天看结果。必须按照以下步骤进行手动验证与配置核对：

直接执行脚本验证语法与权限：
```
/bin/bash /data/scripts/backup_mysql.sh
```
执行后检查归档文件是否生成、大小是否正常：
```
ls -lh /data/backup/mysql/
cat /data/backup/mysql/backup.log
```
检查导出的压缩包完整性：
通过 gzip 测试压缩归档是否存在损坏：
```
gzip -t /data/backup/mysql/production_db_*.sql.gz
```
若无任何输出返回，说明压缩归档完整无破损。

核查 crond 服务的后台状态：

确保系统的 cron 守护进程本身处于活动状态：

# 在 RHEL / CentOS 系统中
systemctl status crond

# 在 Debian / Ubuntu 系统中
systemctl status cron

在配置该方案时，有几种容易出现偏差的认知与做法，下表列出了这些常见问题及其实际原因：

常见做法 / 误区	表象原因与陷阱	标准修正措施
在 crontab 命令行里直接写 mysqldump ... > backup_`date +\%Y\%m\%d`.sql	直接写短命令看似省事，但在 crontab 中 `%` 字符会被默认解析为换行符，导致任务直接报错中断。	将完整逻辑封装到独立 `.sh` 脚本中；若必须在 crontab 行内使用，需转义为 `\%`。
手动执行脚本成功，但 crontab 到期不生成文件	手动执行时加载了个人环境（如 `~/.bashrc`），而 crond 只提供最简基础环境，往往找不到 `mysqldump` 路径。	在脚本开头显式声明 `export PATH=...`，或在调用工具时使用绝对路径（如 `/usr/bin/mysqldump`）。
以为只要配置了定时导出，备份就万无一失	只存不测是隐患之源。如果数据库表结构发生过变动或权限被收回，可能只导出了一个带有错误信息的空文件。	在脚本中检查 `PIPESTATUS[0]` 状态码，并定期在测试机器上执行导入演练。