restic备份到B2失败告警仅报行号？运维告警设计反思

一次只有行号的备份失败告警

2026年10月11日早上6:40，一条严重级别的告警触发了：发往B2的每日restic远程备份任务失败。告警文本只给了一个细节——“exit at line 92”。

这个任务由systemd timer驱动，每天5:30通过orqestra-backup.timer调用/opt/orqestra/scripts/backup-db.sh脚本。告警提示了两个排查方向：orqestra-backup单元的journal日志，以及VPS上的那个脚本。

restic 是一款用 Go 编写的开源命令行备份工具，采用内容寻址的存储模型：每次备份只上传尚未存在的数据块，因此天然支持增量备份与去重。它支持本地目录、SFTP、S3 兼容对象存储等多种后端，B2（Backblaze B2）就是其中常见的一种。restic 执行时会向 stderr 输出进度、警告与错误信息，并在失败时返回非零退出码。正因为它把真正的原因（仓库锁冲突、认证失败、网络中断、存储配额超限等）写在自身输出里，脚本层若不捕获这些输出，排障者就只能看到外壳脚本的行号。

行号告诉你“停在哪”，却不告诉你“为什么停”

告警里最重要的信息缺失了：restic自己打印了什么。是B2上的仓库不可达？是restic本身返回错误？还是脚本更早某一步出了问题？这些全都无从得知。

行号只能定位脚本中断的位置，无法解释中断的原因。对于排障来说，这几乎是无效信息——值班工程师收到告警后仍然必须打开日志从头翻起，告警并没有替他节省任何时间。

告警设计的常见误区：用状态词和位置代替真正的错误

很多自动化脚本的告警逻辑停留在“进程退出码非零就报警”的层面，然后把行号或状态词塞进通知里。表面上看信息完整，实则把最关键的上下文——工具自身的错误输出——丢在了日志里。

当任务链路是“systemd timer → shell脚本 → restic → B2”时，失败可能发生在链路的任何一环。只报一个行号，等于把定位成本完全转嫁给接收告警的人。尤其在凌晨触发、需要快速判断是否需要人工介入的场景下，这种设计的代价很高。

systemd timer 是 systemd 提供的定时任务机制，由一对单元组成：.timer 单元定义触发时间（类似 cron），.service 单元定义实际执行的命令。相比 cron，它的优势在于可用 systemctl list-timers 查看下次触发时间、支持 Persistent=true 补跑错过的任务，并且所有输出统一进入 journal。用 journalctl -u orqestra-backup 即可按单元检索完整日志。理解这一点很关键：timer 只负责“何时启动”，失败原因的原始证据始终留在对应 service 单元的 journal 里，告警文本若不含这段输出，就等于把证据与通知割裂开了。

一个可直接落地的改进原则

原文给出的建议很明确：当restic任务通过脚本在systemd timer下运行时，让告警携带restic自身的错误输出，因为一个行号加一个状态词不足以支撑任何行动。

具体做法上，可以在脚本中捕获restic命令的stderr，并在失败时将其写入告警正文；同时保留journal中完整的原始输出作为兜底。这样告警本身就能回答“哪一步失败、失败原因是什么”，而不是把工程师引向日志再做二次检索。

这次事件没有给出根因，作者也明确拒绝从行号猜测原因。它留下的价值不在于某次备份为何失败，而在于一次关于告警信息密度的提醒：告警的职责是传递可行动的信息，而不是传递一个指向日志的指针。

在 shell 脚本中捕获子命令错误输出的常见写法是：用 err=$(restic backup ... 2>&1 >/dev/null) 把 stderr 收进变量，再判断 $?；或使用 set -o pipefail 配合 tee 同时落盘与转发。需要留意的是，restic 的部分输出（如进度）默认写入 stderr，因此最好用 --quiet 或 --json 控制输出量，再对捕获内容做截断（例如只保留最后 20 行），避免告警正文过长被通知渠道折叠。把这段截断后的文本嵌入告警，就能在不打开 journal 的情况下判断是否需要立即人工介入。