CNCF 于 2026 年 9 月 10 日发布了一份基于三个可复现故障场景的指南，旨在测试有状态 Kubernetes 应用的灾难恢复，而不是仅仅观察备份是否以 Completed 状态结束。这些实验可以从实验室仓库在笔记本电脑上运行，使用了一个包含四行已知内容的 PostgreSQL 应用，因此可以验证实际恢复结果，而不是依赖通用状态指标。
该材料由 CNCF 大使 Saiyam Pathak 和 Saloni Narang 编写。其范围仅限于 Kubernetes 内应用状态的恢复；不涉及合规框架、产品比较、底层云或数据中心基础设施恢复。Velero 和 CSI Snapshot 接口等工具作为这些场景的参考实现出现，而这些故障模式同样适用于承担相同角色的工具。
备份完成并不能证明可恢复性
在第一个场景中，Kubernetes 备份的组件被拆分为 YAML 格式的资源定义和持久卷数据。实验室使用 Velero，通过将数据传输到位于两个集群之外、兼容 S3 的对象存储来完成备份。对 DataUpload 对象的检查显示，47,989,888 字节的卷数据确实被传输到了外部存储。
删除包括 PVC 在内的命名空间后，恢复过程在约两分钟内恢复了同样的四行数据。但 CNCF 警告称，保护卷数据并不会自动使数据库备份在应用层面保持一致；应用可能需要执行 flush 或 quiesce 操作。此外，在不同基础设施上进行恢复可能需要调整 StorageClass 以及其他转换，这些都必须由团队设计并测试。
更重要的是，备份工具会将资源恢复到一个预先存在的集群中，而不会创建节点、网络、负载均衡器或 DNS。因此，恢复计划必须明确规定接收备份的环境，并在需要时将 Kubernetes 恢复交由基础设施即代码或 Cluster API 负责。
Git 恢复意图，但不会恢复存储状态
在第二个场景中，生产集群被关闭，而恢复集群已预先存在，其中包含一个连接到 Git 仓库的 GitOps 控制器，以及一个连接到共享存储的备份工具。应用同步成功，StatefulSet 处于运行状态，监控面板也显示为正常，但查询数据库时返回错误：relation "attendees" does not exist。
原因并不是 Kubernetes 或 GitOps 出现故障。仓库中只包含定义，因此控制器重新创建了 StatefulSet、Service 和一个新的空存储卷。实际上，Git 存储的是声明状态或团队意图，而备份存储的是真实数据；两者任何一个都无法单独完整恢复应用。
实验室采用的恢复方法包括：删除同步创建的空应用，然后从备份存储中恢复应用及其卷，最后将数据与预期内容进行比较。从停止生产到显示经过验证的数据，实际演练耗时四分钟，复测耗时略少于两分钟。CNCF 说明，这些数字只涵盖已编程的部分，不包括发现事件、作出决策、切换流量以及返回原始环境。
单独快照可能产生从未存在过的恢复点
第三个场景测试了一个使用两个相互关联存储卷的应用：一个用于订单，另一个用于支付。实验程序以每秒五次的速率写入匹配的数据对，并要求每笔支付都对应一个订单。当以五秒间隔分别创建两个快照时，每个快照单独看起来都已就绪且正常，但恢复后发现，最后记录的订单为 108352，而支付为 108377，也就是有 25 笔支付没有匹配订单。
结果表明，每个独立存储操作成功，并不能保证多存储卷应用的一致性；两个快照合在一起可能描述了一个实际上从未存在过的时间点。材料指出，在生产环境中，当备份工具逐个处理大量 PVC 时，这一差异可能会进一步扩大。
在 Kubernetes 1.36 中达到 GA 状态的 VolumeGroupSnapshot，提供了通过单个标签识别存储卷，并通过 CSI 请求一致恢复点的机制。在协调后的实验中，订单和支付的最后编号均为 109169，二者之间的关系验证成功。但支持情况取决于驱动程序；普通 VolumeSnapshots 的支持并不能证明支持组快照，而且截至 2026 年年中，实验室检查的大多数主要云驱动程序尚未实现该功能。同样，必须显式启用 CRD、快照功能以及相关插件。
恢复测试应测量什么？
- 将完整应用恢复到一个此前从未运行过的干净目标环境，而不是仅删除 Pod 并观察其重新创建。
- 使用预期内容验证数据和用户访问路径，而不是只查看资源状态或监控面板的颜色。
- 用时钟测量整个流程，并认识到实际恢复时间包括发现、决策、流量切换以及可能的返回原始环境。
- 使用两个彼此独立的故障域，例如生产集群和恢复集群，并将备份存储置于二者之外。
编辑解读：工具与恢复顺序之间的鸿沟
这些实验凸显的实际变化，是将成功标准从“备份已完成”转变为“正确的数据已恢复且可以访问”。更广泛的限制在于，基础 Kubernetes 并未规定一个用于协调数据、应用、集群、流量和身份的共同契约，也没有提供一个标准化且持久的资源，用于描述应用及其外部依赖的完整恢复单元。因此，即使每一层都有成熟工具，GitOps、备份、基础设施和用户路径之间的边界仍由团队负责。CNCF 提到，由 CNCF TAG Operational Resilience 发起的 Cloud Native Business Continuity 倡议，旨在汇集有关生态系统差距分析、恢复指南和参考架构的贡献。