1. 灾备准入概述
1.1 灾备准入的定义
灾备准入（Disaster Recovery Admission）是指在生产环境与灾备环境之间建立一套可量化、可验证、可审计的准入标准，确保只有满足特定一致性、完整性和时效性要求的备份数据，才能被用于恢复演练或真实切换。它并非单纯的备份策略，而是将“备份是否可用”这一模糊判断转化为明确的准入条件，从而消除恢复时的决策盲区。
核心公式： 灾备准入 = 备份有效性验证 + RPO/RTO 对齐检查 + 恢复路径可执行性确认
在 etcd 集群场景中，灾备准入机制需要回答三个关键问题：
- 备份数据是否完整？ —— 快照是否包含所有已提交的 key-value 条目，WAL 日志是否连续无断裂。
- 备份数据是否满足 RPO 目标？ —— 恢复点与故障点之间的数据丢失量是否在容忍范围内。
- 恢复流程是否可执行？ —— 从备份存储到目标集群的传输、解压、校验、启动链路是否经过预演。
1.2 灾备准入在 etcd 集群中的重要性
etcd 作为 Kubernetes 控制面的状态存储，其数据完整性直接决定整个容器编排平台的可用性。一次未经准入校验的恢复操作，可能导致：
- 数据不一致： 使用过期或不完整的快照恢复，造成 Service、Pod、ConfigMap 等资源对象丢失或状态错乱。
- 集群分裂： 恢复后的 etcd 成员与现有成员无法建立 Raft 共识，形成脑裂。
- RPO 违规： 恢复点距离故障点超过业务容忍阈值，导致大量事务数据永久丢失。
| 风险场景 | 无灾备准入 | 有灾备准入 |
|---|---|---|
| 备份文件损坏 | 恢复时才发现，已错过切换窗口 | 备份完成后立即校验，提前告警 |
| RPO 超限 | 恢复后业务投诉数据丢失 | 恢复前自动比对时间戳，拒绝准入 |
| 版本不兼容 | etcd 启动失败，回滚困难 | 准入阶段检查 API 版本兼容性 |
| 恢复路径不可达 | 手动拷贝，耗时不可控 | 预定义恢复管道，自动执行 |
最佳实践： 将灾备准入检查点嵌入到备份流水线的末端，形成“备份即验证”的闭环，而非等到灾难发生时才临时检查。
1.3 RPO 与 RTO 基本概念
RPO（Recovery Point Objective）和 RTO（Recovery Time Objective）是灾备设计中两个最核心的量化指标，也是灾备准入判断的基准线。
| 指标 | 全称 | 定义 | etcd 场景示例 |
|---|---|---|---|
| RPO | Recovery Point Objective | 允许丢失的最大数据时间窗口 | RPO = 5 分钟，意味着最多容忍丢失最近 5 分钟的写入 |
| RTO | Recovery Time Objective | 从故障发生到业务恢复的最大允许时间 | RTO = 30 分钟，意味着必须在 30 分钟内完成 etcd 集群重建 |
在灾备准入流程中，RPO 和 RTO 分别对应两个不同的检查维度：
- RPO 对齐检查： 备份数据的时间戳与故障时间戳之间的差值 ≤ RPO 阈值。例如，若 RPO 为 5 分钟，则备份时间必须晚于故障时间前 5 分钟。
- RTO 对齐检查： 从备份存储读取到 etcd 集群完全对外提供服务的时间 ≤ RTO 阈值。这要求恢复流程的每个步骤（传输、解压、校验、启动、健康检查）都有明确的耗时上限。
常见误区： 很多团队只关注 RPO 而忽略 RTO。在 etcd 恢复场景中，即使备份数据完全满足 RPO，如果恢复流程耗时过长导致 RTO 超限，同样会造成业务长时间中断。灾备准入必须同时检查两个指标。
1.4 灾备准入的三大检查维度
基于上述概念，我们将灾备准入拆解为三个可操作的检查维度，每个维度都直接与 RPO/RTO 目标挂钩：
| 检查维度 | 检查内容 | 关联指标 | 准入判定条件 |
|---|---|---|---|
| 数据完整性 | 快照哈希校验、WAL 连续性检查、key-value 计数比对 | RPO | 校验通过 → 准入；校验失败 → 拒绝并告警 |
| 时效性 | 备份时间戳与当前时间差值、RPO 阈值比对 | RPO | 差值 ≤ RPO → 准入；差值 > RPO → 触发增量备份或拒绝 |
| 恢复可行性 | 恢复路径可达性、磁盘空间、etcd 版本兼容性、预演结果 | RTO | 预演耗时 ≤ RTO → 准入；预演耗时 > RTO → 优化流程或扩容资源 |