1. 灾备基础概念
1.1 什么是灾备
灾备（Disaster Recovery, DR）是指通过预先制定的技术策略、流程规范和基础设施部署，在信息系统遭受灾难性故障时，能够将关键业务和数据恢复到可接受状态的一系列能力集合。灾备的核心目标不是“防止故障发生”，而是“在故障发生后，业务仍能持续或快速恢复”。
核心公式： 灾备能力 = 数据保护策略 × 恢复执行效率 × 定期验证机制
1.2 RPO 与 RTO 定义
RPO 和 RTO 是衡量灾备方案有效性的两个核心指标，任何灾备架构设计都必须围绕这两个参数展开。
| 指标 | 全称 | 定义 | 典型值（云原生） | 影响要素 |
|---|---|---|---|---|
| RPO | Recovery Point Objective | 可接受的最大数据丢失时间窗口，即从灾难发生时刻回溯到最后一个可用备份点的时间差 | 秒级～分钟级（异步复制）；0（同步复制） | 复制频率、网络带宽、数据变更速率 |
| RTO | Recovery Time Objective | 从灾难发生到业务系统完全恢复可用的最大可接受时间 | 分钟级～小时级（容器化应用）；秒级（多活架构） | 基础设施启动速度、数据加载时间、依赖服务就绪顺序 |
实践要点： RPO 决定备份策略（全量/增量/实时流），RTO 决定恢复架构（冷备/温备/热备/多活）。在云原生环境中，RTO 的瓶颈往往不在数据加载，而在容器编排、服务网格和配置同步的启动延迟。
1.3 灾备等级划分
国际标准 SHARE 78 将灾备划分为 7 个等级，结合云原生场景，可归纳为以下 4 个主流等级：
- Tier 0 – 无灾备： 无任何备份或恢复计划，数据丢失即永久丢失。仅适用于非生产或实验环境。
- Tier 1 – 冷备（Cold Standby）： 定期备份数据到异地存储，恢复时需手动搭建基础设施、加载数据。RTO 通常 > 24 小时，RPO 为 1～7 天。
- Tier 3 – 温备（Warm Standby）： 备用站点已部署基础设施和部分服务，数据通过异步复制保持近实时同步。RTO 为 1～4 小时，RPO 为分钟级。
- Tier 5 – 热备/多活（Hot Standby / Active-Active）： 多个站点同时承载业务流量，数据实时双向同步，任一站点故障后流量自动切换。RTO 为秒级，RPO 接近 0。
1.4 云原生环境下的灾备挑战
云原生架构（容器、Kubernetes、微服务、声明式 API）在带来弹性和敏捷性的同时，也给传统灾备方案带来了全新的挑战。以下 6 个核心挑战是构建云原生灾备方案时必须解决的：
| 挑战领域 | 具体问题 | 传统灾备方案失效原因 | 云原生应对思路 |
|---|---|---|---|
| 1. 有状态容器 | StatefulSet + PVC 的分布式数据一致性难以保证 | 传统基于 IP/主机名的备份无法感知 Pod 漂移 | CSI 快照 + 应用级一致性组 |
| 2. 声明式配置 | CRD、ConfigMap、Secret 等资源版本依赖复杂 | 只备份数据不备份资源定义，恢复后无法匹配 API 版本 | Velero 资源对象备份 + 版本兼容性校验 |
| 3. 服务网格 | Sidecar 代理、流量路由规则、mTLS 证书的恢复顺序 | 忽略 Sidecar 注入和证书有效期，恢复后网络不可达 | 网格控制面快照 + 证书生命周期管理 |
| 4. 多集群拓扑 | 跨集群服务发现、DNS 解析、Ingress 路由的依赖关系 | 单集群恢复方案无法处理跨集群流量切换 | Cluster API + 全局负载均衡策略 |
| 5. 持续变更 | GitOps 驱动的频繁部署导致备份窗口不稳定 | 固定时间窗口备份无法捕获频繁的配置变更 | 事件驱动备份 + 变更日志回放 |
| 6. 成本与合规 | 跨区域数据驻留要求、快照存储成本爆炸 | 全量备份策略导致存储成本线性增长 | 分层备份（热/温/冷）+ 数据本地化标签 |
常见误区： 很多团队认为“容器是无状态的，所以灾备只需要备份 PVC 即可”。实际上，Kubernetes 集群的灾备必须同时覆盖：etcd 数据、资源对象清单、持久卷数据、镜像仓库、Helm Chart 和自定义 CRD。缺少任何一环，恢复后的集群都无法正常工作。
1.5 云原生灾备架构总览
下图展示了云原生环境下灾备方案的核心组件及其交互关系，后续章节将逐一深入每个模块的设计与实现。