备份绿了四个月，恢复时系统却崩了

周三下午两点，季度灾难恢复演练准时开始。备份状态灯绿了整整四个月，恢复流程执行得干净利落——数据完整，虚拟机启动，数据库服务正常运行。然后应用在首笔交易时崩溃。

接下来的三小时，团队疯狂排查备份链路。没人想到去检查环境本身。

备份没有问题。从来就不是备份的问题。这是一种"恢复配置漂移"——属于数据保护故障中最隐蔽的一类：保护平面报告成功，恢复平面却输出无用结果。

演练验证了备份完整性和恢复机制，也就是保护平面。但它没有验证环境状态，即恢复平面。四个月来，静默的漂移在备份捕获点和恢复目标之间不断累积。备份任务始终显示绿色，没有任何告警暴露这个缺口，直到恢复流程撞上一个早已物是人非的环境。

四个月里，三条漂移向量悄然堆积。每一条单独都不可见，每一条在恢复时的应用层都是致命的。

第一条：服务端点变更

某个内部服务端点被手动更新，从未提交回基础设施即代码（IaC）。恢复配置仍指向旧依赖。恢复后的应用向外请求一个已不复存在的端点，首笔交易失败。备份与此无关。

第二条：内部CA信任链轮换

内部证书颁发机构的信任路径被自动化流程轮换，配置引用却从未更新。恢复后的应用无法再验证上游身份认证——证书链验证在首次认证调用时静默失败。备份在捕获时刻是应用一致的，但它所假设的信任链已不存在。

第三条：东西向网络策略收紧

安全团队三个月前收紧了东西向流量规则，恢复手册从未同步更新。恢复后的应用在首笔交易时尝试访问服务依赖，撞上策略阻断。变更是正确的，恢复文档是错的。

这三条没有一条被标记为备份问题。全部三条在应用实际运行于恢复环境之前都是不可见的——而这个环境已经累积了三处与备份假设状态的偏离。

这就是"恢复漂移缺口"。

备份是一致的，恢复环境却不是。"一致性边界"就是这两个状态的分歧点——备份所知与现实环境之间的那条线。每一次未追踪的手动变更都在拓宽它；每一次更新配置却未提交回代码的自动化流程都在拓宽它；每一次未同步到恢复手册的安全策略变更都在拓宽它。备份任务始终绿灯，没有任何东西暴露缺口，直到恢复撞上一个已经前进的环境。

这个缺口不会自我宣告。它等待演练——或者更糟，等待真正的故障。

传统的框架把备份和恢复当成同一件事。备份成功被误读为恢复就绪。监控仪表盘强化了这种幻觉：备份作业状态、恢复点目标达成率、数据缩减比——全是保护平面的指标。恢复平面没有等效的可观测性。环境状态没有被持续验证，配置漂移没有被追踪，依赖一致性没有被量化。缺口在数据中不存在，直到恢复流程试图跨越它。

团队花了三小时才意识到检查方向错了。这不是备份故障，是环境同步故障。恢复配置假设了一个四个月前的世界，而那个世界的端点、证书和防火墙规则都已经移动。

修复本身很简单：更新端点引用、刷新CA配置、调整网络策略。但真正的修复是认知层面的——承认保护平面和恢复平面是两个需要分别验证的系统。

这次演练的价值不在于证明了备份有效，而在于暴露了验证机制的盲区。四个月绿灯，一次崩溃，三小时弯路。漂移不会出现在任何仪表盘上，直到有人试图真正使用被保护的东西。

缺口一直在那里。只是没人去看。