crontab不是服务而是调度器，部署自动备份的关键是编写健壮可验证的备份脚本：密码用~/.my.cnf安全存储、innodb加--single-transaction、备份后校验空文件；crontab执行需用绝对路径、显式path、重定向stderr、root权限运行；文件名含秒级时间戳，清理前先筛非空文件；脚本需set -e、检查磁盘空间、记录日志。
Crontab 本身不是服务，而是 Linux 的定时任务调度器；所谓“部署自动备份服务”，本质是用 crontab 调度一个健壮、可验证的数据库备份脚本。关键不在“装个服务”，而在让每次备份真发生、失败能察觉、旧文件不堆积、恢复时可用。
备份脚本必须做对的三件事
手动跑通 ≠ crontab 跑通。绝大多数静默失败，源于脚本没处理好环境、权限和一致性。
-
密码绝不硬编码：删掉所有 -p'xxx' 或 DB_PASS="xxx"。改用
~/.my.cnf（如 root 运行就放/root/.my.cnf），内容仅含[client]段，权限严格设为600 -
InnoDB 表必加
--single-transaction：否则高并发下导出可能跨事务不一致；MyISAM 表才需--lock-all-tables（会阻塞写入） -
备份后立刻校验有效性：用
if [ ! -s "$BACKUP_FILE" ]; then echo "empty backup"; exit 1; fi，空文件说明 mysqldump 已失败但被忽略
crontab 执行前必须检查的四个点
crond 启动时只加载极简环境，PATH 通常只有 /usr/bin:/bin，也不读 .bashrc。
-
所有命令写绝对路径：
/usr/bin/mysqldump、/bin/gzip、/usr/bin/find—— 用which mysqldump确认真实路径 -
脚本开头显式声明 PATH：
export PATH="/usr/bin:/bin:/usr/local/mysql/bin" -
错误输出必须重定向到日志：
2>> /var/log/mysql_backup.log，否则 stderr 全丢，失败无声无息 -
用
sudo crontab -e编辑 root 任务：普通用户 crontab 无法访问 MySQL 配置、写系统级备份目录（如/backup/）
文件命名与清理要防坑
名字不带时间戳，或清理逻辑靠 -mtime，是线上事故高频原因。
-
文件名含秒级时间戳：
$(date +\%Y\%m\%d_\%H\%M\%S)（%要转义），避免同一分钟多次运行冲突 -
清理旧备份别用
find ... -mtime +7：一次失败备份留下空文件，-mtime仍认为它是“新文件”而跳过删除；应先find ... -size +0筛非空文件，再按日期解析或加-maxdepth 1安全清理 -
压缩与导出合并成一步：
mysqldump | gzip > $BACKUP_FILE，避免中间生成未压缩的大临时文件撑爆磁盘
生产可用的最小结构示例
不追求功能堆砌，只保核心动作可验证：
- 脚本首行写死解释器：
#!/bin/bash - 开头
set -e：任一命令失败立即退出 - 备份前检查磁盘空间，超 90% 使用率自动跳过并记录告警
- 成功后打日志：
echo "[$(date)] OK: ${DB_NAME}_${DATE}.sql.gz" >> /var/log/mysql_backup.log - crontab 条目示例（每天凌晨 2 点）：
0 2 * * * /opt/scripts/mysql_backup.sh 2>> /var/log/mysql_backup.log
