备份连续三晚静默失败：SAP B1 RSP 备份监控的教训
SAP Business One 环境用 RSP（Remote Support Platform） 做所有公司库的每晚定时备份。一次例行周检时，在 Backup History 里发现不对劲：连续三个晚上、跨多个数据库，状态全是 DB Backup: Failed，Size 一栏赫然写着 0 B。
更刺激的是：三天之后，备份又自己恢复成功了，仿佛什么都没发生过。
当时 Backup History 里看到的模式（库名已匿名）：0 B 三连，然后无声”自愈”
为什么三天都没人知道
因为它是静默失败：
- RSP 的备份任务失败不会弹任何通知——失败记录只是安静地躺在 Backup History 列表里；
- 我们环境里 RSP 的 E-Mail Connection 一直没有配通（Connection Status 里它是灰色的），所以邮件告警通道等于不存在；
- 备份目录里躺着一堆 0 B 的文件——看起来「有备份」，实际上什么都恢复不出来。这比目录空空如也更危险，因为空目录反而会引起警觉。
那三个晚上如果正好赶上勒索软件或者磁盘故障，损失就是整整三天的业务数据。
排查与处理
在 RSP 里逐库核对（Configuration → Backup Management → Backup History，按 server + database + 日期范围过滤）：
- 拉出所有库的失败清单：哪些库、哪几晚、失败前后的备份是否完整；
- 确认失败窗口前后的备份文件实际大小正常（几百 MB 级别，不是 0 B）且能打开；
- 失败区间只有那三个晚上，之后全部恢复 Success——典型的「环境短暂异常」特征（备份目标共享不可达、磁盘满、服务重启之类）。事后没能从日志里钉死唯一根因，但处理重点不在这——在于以后不能再靠运气发现。
固化下来的监控 SOP
- 每周固定检查 RSP Backup History（我们放在周一）：不是瞄一眼最新一条，而是把过去 7 天所有库过一遍，专门找 Failed 和 0 B；
- 检查备份文件本身：抽查文件大小趋势——正常的全量备份大小是缓慢增长的（比如 558 MB → 563 MB），突然掉到 0 或暴跌都是红灯；
- 把告警通道修通：邮件告警没配通的监控系统等于没有监控。这条是本次最大的整改项；
- 定期恢复演练：备份的唯一意义是能恢复。0 B 事件之后，恢复测试从「想起来才做」升级成固定日程。
教训
备份系统最危险的状态不是「坏了」，而是「看起来是好的」。
- 任何备份方案上线时，第一个要验证的不是备份能不能跑，而是失败时你会不会知道；
- 0 B 的备份文件是最阴险的故障形态——监控规则里要显式检查文件大小，不能只看任务状态；
- 人工周检不可靠但聊胜于无；它应该是告警通道之外的兜底，而不是唯一防线。