备份定时任务的关键
生产备份的可靠性不在脚本多复杂，而在失败能被发现。骨架是四件事：flock 防重入、日志留痕、退出码与产物大小双重校验、失败立即告警。只有把「最近一次成功时间」纳入监控，才能避免以为在备、其实早已停跑的典型事故。
基本信息
| 适用 | Linux + cron / systemd timer + mysqldump 或 xtrabackup |
|---|---|
| 防重入 | flock -n 锁文件，上一次未跑完直接跳过并告警 |
| 双校验 | 退出码 + 产物大小或 gzip 完整性 |
| 告警出口 | mail、企业微信机器人、监控系统回调 |
crontab 与脚本骨架
crontab 与脚本骨架
# crontab：每天 02:15 备份，加锁防重入，输出全部进日志
15 2 * * * flock -n /var/lock/mysqldump.lock /usr/local/bin/mysql_backup.sh >> /var/log/mysql_backup.log 2>&1
# /usr/local/bin/mysql_backup.sh（节选）
set -euo pipefail # 任一环节失败立即退出，管道错误也算失败
export MYSQL_PWD=$(cat /etc/mysql-backup.pwd) # 避免口令出现在 ps 输出里
OUT=/data/backup/all_$(date +%F).sql.gz
mysqldump -uroot --single-transaction --all-databases --master-data=2 | gzip -6 > "$OUT" # 5.7 用 --master-data，8.0 用 --source-data
[ ${PIPESTATUS[0]} -eq 0 ] || { echo "BACKUP FAILED rc=${PIPESTATUS[0]}"; mail -s 'MySQL backup FAILED' dba@example.com </dev/null; exit 1; }
size=$(stat -c%s "$OUT"); [ "$size" -gt 104857600 ] || { echo "WARN backup too small: $size"; exit 1; }
gzip -t "$OUT" && echo "OK $(date +%F) size=$size"失败信号逐项读法
| 信号 | 含义 | 处理方向 |
|---|---|---|
| 退出码 1 | 明确失败：磁盘满、连接被拒、权限不足 | 立即告警，查 error log 与磁盘水位 |
| 退出码 2 | 警告：部分表被跳过或对象无法读取 | 需人工确认是否可接受，不能当成功 |
| 产物大小骤降 | 备份不完整或被中断 | 按历史大小曲线设阈值下限并告警 |
| 日志停在某个库 | 大表阻塞或锁等待导致长时间无新输出 | 确认与业务高峰是否重叠，调整时间窗 |
| gzip -t 失败 | 产物被截断 | 排查磁盘与管道中断后重跑 |
典型使用场景
- 每日全量备份加告警，作为误删误改的最后兜底
- 备份时长逼近业务窗口，用大小曲线判断是否需要改增量策略
- 多实例集中备份，用统一脚本与集中日志避免各机器脚本不一致
- 审计要求保留可验证产物，用 gzip -t 与恢复演练出证据
- 磁盘故障前兆排查：备份失败往往先于业务报错暴露磁盘问题
监控要盯「最近成功时间」而不是「任务有没有跑」：脚本自身卡死或机器重启后任务没跑，只有成功时间戳能暴露，脚本内发信反而失效。
只有备份没有恢复演练等于没有备份，每季度在隔离环境做一次真实恢复并计时，才能验证备份可用与 RPO、RTO 是否达标。