手动好用 cron 却出空备份:定时任务避坑全复盘

那天下午,数据库要做一次例行回滚演练,我胸有成竹地去拿前一晚的备份——毕竟那个备份脚本我亲手写的,加进 crontab 跑了快两个月,从没报过错。结果打开备份目录我整个人都凉了:最近好几天的备份文件全都躺在那儿,大小却是 0 字节,空的。再往前翻,某一天之后,所有备份就齐刷刷地变成了空壳子。而这段时间里,监控没有一条告警,cron 的退出码忠实地记录着"成功"。

我的第一反应是脚本坏了。可把脚本拷到终端里手动一跑,备份文件完美生成,几百兆的数据稳稳当当。同一个脚本,我手动跑就好,cron 跑就出空文件——这种"在我机器上明明好好的"的诡异,最是磨人。我盯着那行 crontab 看了半天,才慢慢回过味来:问题根本不在脚本的逻辑,而在于 cron 把它放进了一个和我的登录终端截然不同的环境里去执行。

真凶最终锁定在一个被我视作理所当然的东西上:脚本里调用了一个装在 /usr/local/bin 下的工具,我在终端里因为 PATH 配好了,直接敲命令就能用;可 cron 执行时的 PATH 短得可怜,根本找不到这个命令,于是那一步静默失败,后续把失败的(空)输出重定向进了备份文件,最终落下一个个 0 字节的空壳。而这一切,因为脚本没有任何错误检查,被包装成了"成功"。这篇文章,就从这次"沉默的空备份"事故出发,把定时任务最容易踩的那些坑,一次性掀开。

先摆几个关于 cron 的想当然

动手复盘前,先把我自己曾经深信、后来被现实教育的几个念头列出来,你也对照看看。

这些念头的共同根子,是把 cron 想象成"一个替我敲命令的隐形助手",以为它和我坐在终端前敲的是同一回事。可事实是,cron 启动任务时给的是一个极度精简、近乎赤裸的环境,你在终端里习以为常的种种便利,它一概不认。要理解这次事故,得先看清这个环境到底有多"穷"。

第一件事:cron 的执行环境,比你想象的穷得多

当你在终端里敲命令时,你其实站在一个被精心布置过的环境里:登录时系统加载了 /etc/profile、你的 ~/.bash_profile、~/.bashrc,把 PATH 拼得长长的,把各种环境变量、别名、函数都给你准备好了。而 cron 执行任务时,走的是一条完全不同的路:它启动的是一个非交互、非登录的 shell,上面那些初始化文件一个都不会加载。

结果就是,cron 里的 PATH 通常只有可怜的 /usr/bin:/bin(具体看系统),你装在 /usr/local/bin、/opt/xxx/bin 或者用版本管理工具(nvm、pyenv、conda)装的命令,统统找不到。其它环境变量(语言、时区、各种自定义配置)也大多缺席。下面这张图,把"手动执行"和"cron 执行"两条路并排画出来,差别一目了然:

看懂这张图,我那次事故的来龙去脉就清楚了:左边手动执行的路一路绿灯,右边 cron 的路在"找命令"这一步就断了。脚本本身没有一行逻辑是错的,它只是被丢进了一个找不到工具的环境里。所以排查定时任务问题,第一句要问自己的永远是:这脚本是在 cron 那个"穷环境"里,还是在我这个"富终端"里跑的?接下来,我们就从怎么把这个环境差异补上开始。

第二件事:先复刻 cron 的环境,再谈调试

既然根因是环境差异,排查的第一步就不该是盯着脚本逻辑死磕,而是把 cron 的环境复刻出来,让问题在你眼皮底下重现。最直接的办法,是在 crontab 里临时加一行,把 cron 当时的环境完整 dump 到文件里:

# 临时塞进 crontab,捕获 cron 真实的环境快照
* * * * * env > /tmp/cron_env.txt 2>&1

# 等它跑一次后,对比你终端里的 env
# 重点看 PATH 这一行,你会发现它短得吓人
cat /tmp/cron_env.txt | grep PATH
# 可能只有: PATH=/usr/bin:/bin

拿到这份快照,你就能用它来模拟 cron 执行脚本,在终端里复现那个"穷环境",而不必干等下一次定时触发:

# 用一个干净、近似 cron 的环境跑脚本,问题立刻重现
env -i PATH=/usr/bin:/bin /bin/sh /path/to/backup.sh
# env -i 清空所有环境变量,只给最小 PATH
# 如果这样跑也出空文件,就坐实了是环境问题

这一招的价值在于:它把"偶尔半夜才发作、还不报错"的幽灵问题,变成了你随时能在终端里复现、观察的确定性问题。调试的第一原则,从来都是先让 bug 稳定重现,环境复刻就是定时任务这一类问题的"重现按钮"。

第三件事:在脚本里显式声明环境,别赌 cron 给你

定位到 PATH 问题,解法有好几层,从糙到精。最糙但最有效的一招:脚本里所有外部命令都用绝对路径,谁也别依赖 PATH。不过命令一多就很啰嗦,更工程化的做法,是在脚本开头显式声明自己需要的环境,把不确定性收回到自己手里。

#!/bin/bash
# 在脚本开头自己定义 PATH,把需要的目录补全
export PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin
# 如果脚本依赖语言运行时(node/python/...),把它们的路径也补上
export PATH=$PATH:/opt/node/bin

# 关键:别依赖 cron 帮你 cd 到某个目录
# cron 的工作目录通常是执行用户的家目录,相对路径极易踩坑
cd /www/wwwroot/myapp || exit 1   # 用绝对路径,并检查 cd 是否成功

# 之后再用命令就稳了
mysqldump -u root mydb > /backup/mydb_$(date +%F).sql

还有一种更省心的方式:让 cron 通过登录 shell 来执行,从而加载你的初始化文件。不过这要求你的环境变量确实写在那些文件里,且适用于该用户:

# 在 crontab 里直接给 SHELL 和 PATH 赋值(cron 支持顶部赋值)
SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin
MAILTO=ops@example.com

0 3 * * * /path/to/backup.sh

# 或者让命令走一次登录 shell,加载 profile(按需,谨慎用)
# 0 3 * * * bash -lc '/path/to/backup.sh'

三种做法各有取舍:绝对路径最稳但啰嗦;脚本内声明 PATH 兼顾稳健与可读,是我现在的默认选择;crontab 顶部赋值适合一批任务共享同一套环境。无论哪种,核心思想只有一个——脚本要对自己的运行环境负责,别把它赌在 cron 的默认值上。

第四件事:让脚本"失败得响亮",别再静默成功

环境是导火索,但真正让这次事故"潜伏好几天没人发现"的,是脚本本身的另一个致命缺陷:它不做任何错误检查。命令找不到、那一步失败了,脚本却毫不在意地继续往下走,最后以退出码 0 收场。在监控眼里,这就是一次成功。Shell 默认的行为,就是这么"宽容"——而这种宽容,在自动化任务里是灾难。

#!/bin/bash
# 一行,把"宽容"改成"严格",是健壮脚本的起手式
set -euo pipefail
# -e : 任何命令返回非 0 立即退出,不再硬着头皮往下跑
# -u : 用到未定义变量就报错(揪出拼错的变量名)
# -o pipefail : 管道里任意一环失败,整条管道就算失败

BACKUP_FILE=/backup/mydb_$(date +%F).sql

# 显式判断关键步骤的结果,而不是默默接受
if ! mysqldump -u root mydb > "$BACKUP_FILE"; then
    echo "[ERROR] mysqldump 失败" >&2
    exit 1
fi

# 备份完还要校验产物:空文件就是失败,别留下空壳
if [ ! -s "$BACKUP_FILE" ]; then
    echo "[ERROR] 备份文件为空: $BACKUP_FILE" >&2
    exit 1
fi
echo "[OK] 备份成功: $(du -h "$BACKUP_FILE")"

这里两点最关键:一是 set -euo pipefail 把脚本从"出错也往下走"扳成"一出错就停",二是对产物本身做校验——备份文件存不存在、是不是空的(-s 判断非空)。如果我当初哪怕只加了 [ ! -s "$file" ] && exit 1 这一句,那几天的空备份就会立刻以失败退出码暴露出来,而不是静静地骗过所有人。自动化任务的第一要务,不是成功,而是失败时一定要吵闹。

第五件事:把输出接住,否则错误都进了黑洞

"日志里什么都没有"曾让我误以为一切正常,其实真相是:cron 任务的输出根本没人接。cron 默认会把任务的标准输出和标准错误通过本地邮件发给用户,可服务器大多没配邮件,这些输出就直接蒸发了。所以你必须主动把输出重定向到日志文件。

# crontab 里,把 stdout 和 stderr 一起接进带日期的日志
0 3 * * * /path/to/backup.sh >> /var/log/backup.log 2>&1
# >> 追加(别用 > 否则每次覆盖), 2>&1 让错误也进同一个文件

# 想给每次运行单独留底、方便排查,可以按天分文件
0 3 * * * /path/to/backup.sh >> /var/log/backup_$(date +\%F).log 2>&1
# 注意上面的 \% —— 这正是下一节要讲的坑

有了这条重定向,任务里每一句 echo、每一条错误,都会落到日志里。再配合脚本里那些 [ERROR] ... 输出,你就拥有了一条可追溯的线索。更进一步,可以在脚本结尾对接一次告警(企业微信、钉钉、邮件),把"失败"主动推到人眼前——别指望人会主动去翻日志,要让失败自己来找你。

第六件事:那些 crontab 独有的小陷阱

除了环境和错误处理,crontab 文件本身还藏着几个一不留神就中招的语法坑,挑最常见的两个说。

第一个是百分号 %。在 crontab 里,% 是个特殊字符,会被当作换行符,把它后面的内容当成命令的标准输入。这就是为什么上面 date +%F 写进 crontab 必须转义成 date +\%F,否则命令会在 % 处被拦腰截断,行为完全跑偏。第二个是并发与锁:如果任务执行时间可能超过调度间隔(比如每分钟一次但偶尔跑了三分钟),多个实例就会叠在一起跑,轻则抢资源,重则把数据搞乱。用 flock 加一把文件锁能优雅地解决:

# 用 flock 防止任务重叠执行,-n 表示拿不到锁就直接退出
* * * * * /usr/bin/flock -n /tmp/myjob.lock /path/to/job.sh >> /var/log/job.log 2>&1
# 上一次还没跑完时,这一次拿不到锁,自动跳过,绝不并发

到这儿,定时任务的几张主要坑都掀开了。我把排查思路收成一张决策图,下次 cron 任务"行为诡异"时照着走:

把这套动作固化下来,绝大多数"定时任务玄学"都能很快收口。最后,拧成几条可直接照做的铁律:

1. 手动能跑不等于 cron 能跑,先用 env -i 复刻穷环境复现问题,别盯着逻辑空想。
2. 脚本对自己的环境负责,开头显式声明 PATH,关键路径用绝对路径,别赌 cron 默认值。
3. 脚本起手 set -euo pipefail,让任何一步失败都立即、响亮地中止。
4. 对产物做校验,备份这类任务务必检查文件非空,别留下 0 字节空壳。
5. 输出一律重定向到日志(>> log 2>&1),并对失败主动告警,别等人来翻。
6. crontab 里 % 必须转义成 \%,这是最隐蔽也最高频的语法坑。
7. 可能超时的任务加 flock 锁,杜绝实例重叠并发带来的次生灾难。

一张定时任务排错速查表

把这些坑和对策汇成一张表,下次 cron 任务出幺蛾子时对号入座,能省下大把抓瞎的时间。

更进一步:从"能跑"到"可观测"

修好这次事故后,我没有止步于"让备份重新生成",而是顺手把这台机器上所有定时任务做了一轮体检,因为我意识到:一个会静默失败的备份脚本背后,大概率还藏着一堆同样"沉默"的任务。我给它们补上了三样东西。

第一是统一的日志规范:每个任务都重定向到 /var/log/cron/ 下按名字和日期命名的文件,并用 logrotate 定期清理,既能追溯又不撑爆磁盘。第二是失败即告警:脚本结尾统一对接一个发告警的小函数,非 0 退出就把任务名、时间、最后几行日志推到运维群,把"失败"从被动等人发现,变成主动来敲门。

第三,也是对备份这类任务最该有的一层,是"心跳 + 死信"监控。光知道"任务失败了"还不够,你更怕的是"任务压根没启动"——比如 crontab 被误删、机器没开机。这时可以借助 healthcheck 类的探活服务:任务成功结束时去 ping 一个 URL,如果监控端在预期时间窗内没收到这次 ping,就反过来告警。这样,无论是任务跑挂了,还是根本没跑,你都能第一时间知道。对于备份,"没人告诉我它坏了"本身就是最大的风险。

顺带一提:cron 之外,还有 systemd timer

这次事故的几个坑,很多都源自 cron 那个"极简到简陋"的设计。如果你的系统是较新的 Linux 发行版,其实还有一个更现代的选择:systemd timer。它不是要取代 cron,但在一些场景下确实更省心。

相比 cron,systemd timer 有几个实打实的好处:任务的输出会自动进 journald,用 journalctl -u 你的任务 就能查,不再有"输出进黑洞"的烦恼;它能配置依赖关系(比如等网络就绪后再跑)、失败重启策略、资源限制;还有一个 cron 天生缺失的能力——Persistent=true,机器关机错过的任务,开机后能补跑一次,这对备份这类"绝不能漏"的任务尤其有价值。

# /etc/systemd/system/backup.service
[Unit]
Description=Nightly DB backup

[Service]
Type=oneshot
# 环境在这里显式声明,清清楚楚
Environment=PATH=/usr/local/bin:/usr/bin:/bin
ExecStart=/path/to/backup.sh

# /etc/systemd/system/backup.timer
[Unit]
Description=Run backup daily at 03:00

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true        # 错过了(关机)开机后补跑
RandomizedDelaySec=300 # 加随机抖动, 避免一堆任务同一秒挤爆

[Install]
WantedBy=timers.target

当然,systemd timer 配置比一行 crontab 啰嗦,简单任务用 cron 完全够。我的建议是:临时的、简单的任务用 cron;重要的、需要可观测性和补跑能力的任务(尤其是备份),值得花点功夫上 systemd timer。工具没有高下,选对场景才是关键。

最后再补一个贯穿所有定时任务的设计原则:幂等。任务最好设计成"多跑一次也不会出错、不会产生重复副作用"。因为补跑、手动重跑、并发误触发这些情况迟早会发生,一个幂等的任务,能让你在面对这些意外时从容得多——重跑一遍就是了,不必提心吊胆地担心它会不会把昨天的数据又算了一遍、把同一封通知又发了一次。

写在最后

这次事故最让我后怕的,不是那几个空文件,而是它们"假装成功"的那份从容。如果不是那天恰好要做回滚演练,这些 0 字节的空壳可能会一直累积下去,直到某次真正需要备份救命的时刻,我才会发现手里攥着的是一堆空气——而那将是无法挽回的灾难。一个会响亮报错的失败并不可怕,可怕的是一个伪装成成功的失败。

定时任务是运维世界里最不起眼的角落:它们在深夜无人时默默运行,平时几乎不被想起,却常常承载着备份、清理、对账这些"出事就是大事"的职责。也正因为没人盯着,它们身上那些环境差异、静默失败、输出黑洞的坑,才格外致命。这次教训给我最深的提醒是:凡是自动化、无人值守的东西,都必须为"失败"设计,而不只是为"成功"设计。愿你我写下的每一个 cron 任务,都不只是会在顺利时干活,更会在出错时,扯着嗓子把我们叫醒。

如果你手上也管着一台跑着定时任务的服务器,不妨今天就花二十分钟做三件小事自查。第一,把 crontab 列出来(crontab -l),逐条看输出有没有重定向到日志,没有的话先补上 >> log 2>&1——这是成本最低、收益最高的一步。第二,挑出那些"出事就是大事"的任务(备份、对账、数据同步),确认它们脚本开头有没有 set -euo pipefail,有没有对产物做非空校验。第三,随手挑一两个备份文件,真的去解压、去恢复一遍,验证它不是空壳、能用——备份的价值不在于"生成了",而在于"能恢复"。这三件事都不难,却可能在某个需要救命的时刻,让你手里攥着的是真数据,而不是一堆空气。

说到底,定时任务考验的不是你会不会写脚本,而是你有没有一种"为最坏情况兜底"的工程直觉。终端里手动跑通,只是故事的开头;真正的健壮,藏在你对环境差异的警觉、对失败的吵闹、对产物的较真、对补跑的预案里。这些东西平时一文不值,关键时刻却价值连城。愿你我都能记住这次空备份的教训:把每一个无人值守的任务,都当成一个会在深夜独自面对意外的孩子,提前替它想好——万一出事了,它该怎么喊救命。

回头想想,这类问题之所以普遍,是因为我们写脚本时,心里默认的"运行场景"永远是自己在终端里那一次顺顺利利的执行。我们为那个理想场景写代码,却很少为"半夜三点、没人盯着、环境还不一样"的真实场景做准备。可自动化任务百分之九十九的运行,恰恰发生在那个我们从没认真设想过的场景里。把心态从"让它在我面前跑通"转向"让它在我不在时也扛得住",这一步思维的转变,比任何一个具体技巧都更能救你于水火。这,或许才是这次空备份事故留给我最珍贵的东西。

—— 别看了 · 2026