现场是这样的。备份脚本在 shell 里执行正常，写进 crontab 后每天没有产物，/var/log/cron 里能看到触发记录，脚本自己的日志是空的，系统是 CentOS 7.9。
中间走过弯路，把「脚本首行 shebang 写错，被当成 sh 执行」当成主因，改完现象没变。
这类报错背后常见的原因有几处，逐个排除就行。cron 的 PATH 只有系统默认两项，脚本里的命令找不到；环境变量写在 .bashrc 里，非交互执行不会加载；没指定工作目录，脚本里的相对路径全部失效。
第一件事是看 cron 的实际触发与报错
grep CRON /var/log/cron | tail -20然后在 crontab 里显式声明 PATH 和变量
crontab -l | grep -E '^PATH|^MAILTO'脚本里改用绝对路径并切换目录
head -5 /opt/scripts/backup.sh等前面都确认过，再把输出重定向到文件便于定位
crontab -l > /tmp/ct.bak && echo '*/30 * * * * /bin/bash /opt/scripts/backup.sh >> /var/log/backup.log 2>&1' >> /tmp/ct.bak && crontab /tmp/ct.bak恢复的判定其实很直接。下一个调度点后日志文件出现本次执行的输出，备份目录生成当天文件，cron 日志里没有非零退出提示。
排查 cron 最快的办法是把标准输出和错误都重定向到文件，默认它只发本地邮件，很多机器根本没装 MTA。同一份配置在测试环境跑通，不代表线上没事，两边的默认值经常不一样。