脚本路径写错是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 不提供交互式密码输入，会卡住