脚本路径写错是crontab自动化备份失败最常见原因，必须用绝对路径调用脚本及内部命令（如/usr/bin/mysqldump），显式cd切换工作目录，确保权限匹配执行用户，并避免相对路径和shell环境依赖。
脚本路径写错，是 crontab 自动化备份失败最常见也最容易被忽略的原因。根本不在命令逻辑，而在执行环境——cron 不认相对路径、不继承你的 shell 环境、甚至找不到你写的脚本文件。
脚本必须用绝对路径调用
crontab 条目里写的不是“运行什么”，而是“从哪启动什么”。如果你写 0 2 * * * backup.sh 或 0 2 * * * ./backup.sh，cron 会默认在 root 的家目录（通常是 /root）下找这个文件，而你的脚本很可能放在 /home/user/scripts/ 或 /opt/backup/ 里。
- 正确写法是完整路径：
0 2 * * * /opt/backup/mysql_backup.sh - 哪怕脚本和 crontab 属于同一用户，也不能省略路径
- 用
which backup.sh或realpath backup.sh确认真实路径，别靠记忆或 tab 补全
脚本内部也要用绝对路径
脚本里调用的命令（如 mysqldump、rsync、tar）同样面临环境缺失问题。cron 不加载 ~/.bashrc，PATH 往往只有 /usr/bin:/bin，很多工具装在 /usr/local/bin 或 MySQL 自带目录下，直接写命令名就会报 command not found。
- 查命令真实位置：
which mysqldump或find /usr -name mysqldump 2>/dev/null - 脚本中统一用绝对路径：
/usr/bin/mysqldump、/bin/tar、/usr/bin/rsync - 避免在脚本里依赖别名、函数或
source ~/.bashrc—— cron 不支持这些
工作目录不能靠“默认”
脚本里如果用了 cd ..、cp file.txt ./backup/ 这类相对路径操作，而没显式指定起始目录，cron 执行时当前路径可能是 /root 或空，导致文件读写错位、日志写到奇怪位置、甚至删错目录。
- 开头就固定工作目录：
cd /opt/backup || exit 1 - 所有输出路径、输入路径、临时文件路径都写绝对路径，例如：
/backup/logs/而不是./logs/ - 用
pwd或echo "Working dir: $(pwd)"加到日志里，方便排查实际执行位置
权限与归属要匹配执行用户
crontab 是按用户运行的。root 的 crontab 用 root 权限执行，普通用户的 crontab 默认以该用户身份运行。如果脚本需要访问数据库、写入系统目录、或读取敏感配置（如 ~/.my.cnf），权限不对就会静默失败。
- 确认脚本归属：
ls -l /opt/backup/mysql_backup.sh，确保执行用户有读+执行权限 - 数据库备份若用密码文件，确保
~/.my.cnf属于对应用户且权限为600 - 避免在脚本里用
sudo—— cron 不提供交互式密码输入，会卡住
