定时备份脚本需用绝对路径、显式声明PATH、避免相对路径和~，rsync末尾斜杠与--delete行为需明确，日志重定向用绝对路径，MySQL密码存~/.my.cnf，备份前验证磁盘空间与权限。
直接上手就能跑的定时备份同步脚本，核心是「脚本可独立运行 + crontab 只负责调用 + 所有路径和命令都用绝对路径」。任何环节用了相对路径、~、隐式环境变量，十次有九次在 cron 里静默失败。
backup.sh 必须显式声明 PATH 并用绝对路径调用命令
crontab 环境的 PATH 默认只有 /usr/bin:/bin，mysqldump、rsync、tar 很可能找不到。
- 脚本开头必须写：
PATH=/usr/local/bin:/usr/bin:/bin; export PATH - 不要依赖
which rsync或command -v tar动态查路径，直接用绝对路径：比如/usr/bin/rsync、/bin/tar、/usr/bin/mysqldump - 测试方法：切换到 cron 的最小环境运行一次：
env -i PATH=/usr/bin:/bin /usr/local/bin/backup.sh，看是否报 command not found
rsync 同步时末尾斜杠和 --delete 的行为必须对齐预期
rsync 的路径末尾有没有 /，决定同步的是“目录内容”还是“整个目录”。加了 --delete 后，删源就删目标，但第一次运行前不验证会丢数据。
-
/data/→ 同步/data下所有文件到目标目录（不带 data 这层） -
/data→ 同步成DEST/data/（多一层目录） - 首次启用
--delete前，务必先加-n模拟运行：/usr/bin/rsync -avn --delete /data/ user@host:/backup/ - 如果目标是远程且走 SSH，确保
~/.ssh/id_rsa.pub已追加到目标机的~/.ssh/authorized_keys，否则卡住无报错
日志重定向必须捕获 stdout 和 stderr，且不能依赖 ~
cron 不展开 ~，> ~/log 会写进 root 用户家目录下的 ~/log（即 /root/~/log），实际是失败的。
- 日志路径一律用绝对路径：
/var/log/backup.log，不是~/log或$HOME/log - crontab 行末必须加：
>> /var/log/backup.log 2>&1，否则错误信息完全丢失 - 脚本内部也建议每步加
echo "$(date): xxx" >> /var/log/backup.log，方便定位卡在哪一步 - 检查日志权限：
sudo chown root:adm /var/log/backup.log && sudo chmod 644 /var/log/backup.log
MySQL 备份必须避免密码明文，且 mysqldump 路径要确认
硬编码密码在脚本里既不安全又容易因特殊字符（如 $、!）导致语法错误；mysqldump 在不同系统路径不一致，CentOS 是 /usr/bin/mysqldump，Ubuntu 可能是 /usr/local/bin/mysqldump。
- 用
~/.my.cnf存凭证：[client]\nuser=backup_user\npassword=xxx，然后chmod 600 ~/.my.cnf - 脚本中调用：
/usr/bin/mysqldump --defaults-file=/root/.my.cnf mydb > /backup/mydb_$(date +\%Y\%m\%d).sql - 先手动运行一遍脚本，再检查生成的 SQL 文件头是否有
ERROR或空文件 - 若数据库大，加
--single-transaction避免锁表，但仅对 InnoDB 有效
最容易被忽略的其实是磁盘空间清理逻辑——脚本里写了 find /backup -name "*.sql" -mtime +7 -delete，但没确认 /backup 分区是否挂载、是否有写权限、inode 是否耗尽。每次改完脚本，别只看 cron 是否执行，一定去 /backup 目录下 ls -lt 和 df -h 一起看。
