公司刚上线的新系统跑了一周，结果某天早上发现用户数据丢了两天。排查后才发现，备份服务其实早就出了问题，但没人收到通知。这种情况其实在中小企业里太常见了——备份任务失败了，日志里有记录，可没人盯着看。直到出事才意识到，该给系统装个“喇叭”。
告警不是摆设，是最后一道防线
很多人觉得备份只要设置了定时任务就万事大吉。可硬盘会坏、网络会断、脚本会报错。真正靠谱的备份策略，必须包含及时的异常提醒。应用告警设置的作用，就是在问题发生的第一时间推送到你的手机或邮箱，而不是等数据丢了才去翻日志。
比如你用的是常见的 rsync + cron 做本地同步，可以加一段简单的检测逻辑：
#!/bin/bash
if rsync -av /data/ backup@server:/backup/; then
echo "Backup succeeded"
else
curl -X POST https://api.notify.com/alert \
-d '{"msg": "Backup failed on $(hostname)", "level": "critical"}'
fi这段脚本在同步失败时会触发一个 HTTP 请求，把告警发到企业微信或钉钉机器人。不需要复杂的平台，几行代码就能把被动等待变成主动响应。
哪些情况必须设告警
不是所有操作都需要通知，但以下几种场景绝对不能缺：
- 备份任务执行失败或超时
- 磁盘使用率超过 85%
- 关键文件校验不一致（如数据库 dump 后 checksum 异常）
- 远程存储连接中断
有个客户曾遇到 NAS 存储满了，备份文件开始被覆盖。因为没设容量告警，整整一个月的数据只保留了最近三天。后来他们加了 Prometheus 监控 + Alertmanager，一到阈值就发消息到运维群，再也没漏过一次。
别让告警变成骚扰
设太多告警反而会让人麻木。曾经见过一个系统每小时报一次“心跳正常”，结果真正出问题时，大家已经习惯性忽略通知了。合理的做法是区分级别：错误类告警走电话或强提醒，警告类走邮件，普通状态保持静默。
另外，确保每个告警都有明确的处理路径。比如收到“MySQL 备份失败”，应该能立刻查到是权限问题、锁表还是磁盘满。可以在告警信息里带上简短原因，减少排查时间。
现在的备份工具基本都支持集成告警功能。像 BorgBase、Restic 配合 Healthchecks.io，只需填个 webhook 地址，就能实现任务追踪。自建方案也可以用 Zabbix 或 Grafana 搭一套轻量监控，成本不高，但能避免很多半夜救火的尴尬。