必须分三步：写对脚本（含日期变量、压缩、权限检查）、设好执行权限（chmod +x、~/.my.cnf 600）、配准 crontab 时间格式（0 2 *，sudo crontab -e），缺一即静默失败。
能直接用，但必须分三步走清：写对脚本、设好权限、配准 crontab 时间格式——漏任何一环，备份就静默失败。
mysqldump 命令必须带日期变量和压缩
不带时间戳的文件名（比如 backup.sql）会导致每次覆盖，根本没法追溯；不压缩则大库几秒就占满磁盘。实际命令里 date 必须用反引号或 $() 包裹，且格式符里的 % 要转义（\%Y\%m\%d），否则 crontab 解析会出错。
mysqldump -uroot -pRoot@1024 mydb | gzip > /backup/mydb_$(date +\%Y\%m\%d_\%H\%M).sql.gz- 避免明文密码：改用
~/.my.cnf，内容为[client] user=root password=Root@1024，权限必须是600（chmod 600 ~/.my.cnf） - 加
--single-transaction（InnoDB）或--lock-all-tables（MyISAM），否则备份中途写入可能损坏一致性
crontab -e 编辑时必须用 sudo，且注意字段顺序
普通用户 crontab 没法读 MySQL 配置、也没法写系统级备份目录；最常踩的坑是把 0 2 * * *（每天 2:00）错写成 2 0 * * *（每月 2 日 0:00），结果一个月只备一次。
- 用
sudo crontab -e编辑 root 的任务表，确保权限一致 - 时间字段固定为：
分 时 日 月 周，记不住就运行man 5 crontab - 示例：每天凌晨 2 点执行 →
0 2 * * * /bin/bash /backup/mysql_backup.sh - 路径必须写绝对路径（
/bin/bash，不是bash），crontab 不读$PATH
脚本里必须检查磁盘空间和 mysqldump 是否可用
备份失败往往不报错，而是静默跳过——比如磁盘满了、mysqldump 命令没找到、MySQL 进程挂了。脚本开头加两行检测，能省掉半夜爬起来查日志的麻烦。
- 检查空间：
df /backup | awk 'NR==2 {print $5}' | sed 's/%//'，结果 >90 就exit 1 - 检查命令：
command -v mysqldump >/dev/null 2>&1 || { echo "mysqldump not found"; exit 1; } - 加日志重定向：
/bin/bash /backup/mysql_backup.sh >> /backup/backup.log 2>&1，方便追查失败原因
真正难的不是写命令，而是让整个链路在无人值守时稳定跑通：脚本权限、crontab 用户上下文、MySQL 凭据加载时机、磁盘告警阈值——这些点任何一个松动，备份就会“看起来在运行，其实早断了”。
