Kubernetes备份恢复的目标不是“有一份备份文件”，而是在故障发生时能按预期恢复业务。平台团队需要同时回答备什么、怎么恢复、恢复到哪里、多久恢复、恢复后如何验证。本文会围绕灾备设计与恢复演练展开，说明 etcd、声明式资源、应用数据、外部依赖和演练验收的设计重点。
本文定位：面向平台工程、运维、安全或架构团队，关注生产环境中可执行、可审计、可回滚的备份恢复实践。
先定义恢复目标：RPO、RTO 与业务优先级
Kubernetes备份恢复设计要先从业务目标开始，而不是从工具开始。RPO 表示最多允许丢失多久的数据，RTO 表示业务需要在多久内恢复可用。不同系统的要求差异很大：核心交易链路可能需要分钟级恢复，内部报表系统可能可以接受数小时恢复，开发测试环境则更关注可重建性。
建议把应用按恢复优先级分层：
| 等级 | 典型系统 | 关注重点 | 恢复策略 |
|---|---|---|---|
| P0 | 核心交易、认证、支付、入口网关 | 低 RPO、低 RTO、强验证 | 高频备份、异地副本、定期演练 |
| P1 | 业务后台、运营系统、关键 API | 恢复顺序和数据一致性 | 周期备份、依赖清单、变更前演练 |
| P2 | 报表、离线任务、内部工具 | 可重建和成本平衡 | 低频备份、配置保留、必要数据恢复 |
| P3 | 临时环境、实验项目 | 快速重建 | GitOps 或模板重建，少量数据保留 |
这个分层会影响后续所有选择，包括备份频率、保留周期、存储位置、加密方式、恢复环境和演练周期。没有 RPO/RTO 的备份方案，很难判断是否真的可用。
etcd 备份：控制面状态不能替代应用数据
etcd 保存 Kubernetes API 对象状态，例如 Deployment、Service、ConfigMap、Secret、CRD 和部分控制面信息。它是集群恢复的重要对象，但不能替代应用数据库、PVC、对象存储或外部中间件备份。只备份 etcd，最多能帮助你恢复集群声明状态，无法保证业务数据完整。
设计 etcd备份时，重点检查这些问题：
- 备份是否包含证书、加密配置和恢复所需的控制面参数。
- 备份文件是否加密保存，并限制下载和恢复权限。
- 备份是否存放在独立故障域，避免和集群一起丢失。
- 是否定期做恢复验证，而不是只检查备份任务成功。
- 恢复到新集群时，Kubernetes 版本、证书、网络和存储插件是否兼容。
etcd 恢复通常属于高风险操作，适合在隔离环境演练并形成 Runbook。生产事故中不要把 etcd 恢复当成第一反应动作，除非已经确认控制面状态损坏、其他恢复路径无效，并且具备完整回退方案。
应用数据备份：PVC、数据库和对象存储要分层处理
应用数据是 Kubernetes灾备里最容易被低估的部分。很多团队备份了 YAML，却忽略了数据库事务一致性、PVC 快照可恢复性、对象存储生命周期和外部消息队列状态，最终恢复出来的只是“能启动的空壳应用”。
建议按数据类型分别设计：
- 数据库：优先使用数据库自身的备份、日志归档或复制机制，关注一致性、恢复点和回放能力。
- PVC 数据：使用存储系统快照或备份工具时，要确认快照是否应用一致，而不仅是卷级一致。
- 对象存储：检查版本控制、生命周期、跨区域复制和误删恢复策略。
- Secret 与配置：需要加密备份，恢复后要验证凭证是否仍有效，避免恢复出过期密钥。
- 镜像与制品：关键镜像要可重新拉取，私有仓库也要纳入灾备范围。
恢复设计还要写清依赖顺序。比如数据库先恢复，消息队列和缓存再恢复，最后恢复业务 Deployment；如果顺序反了，应用可能反复重启、产生脏数据或触发错误补偿逻辑。
恢复流程：先基础设施，再平台组件，最后业务
一个可执行的恢复流程通常分为三层。第一层是基础设施，包括集群节点、网络、存储类、DNS、证书和镜像仓库访问；第二层是平台组件，包括 Ingress、监控、日志、密钥管理、服务网格或策略控制器；第三层才是业务应用和数据。
推荐的恢复步骤如下：
- 确认事故范围，是单应用、单命名空间、单集群还是区域级故障。
- 准备恢复环境，校验 Kubernetes 版本、网络插件、StorageClass 和镜像仓库连通性。
- 恢复基础配置，例如命名空间、RBAC、Secret、ConfigMap、CRD 和平台组件。
- 按业务优先级恢复数据，再启动依赖该数据的工作负载。
- 执行业务验证，包括健康检查、核心接口、数据一致性和告警状态。
- 记录恢复耗时、失败点和偏离预案的操作，进入复盘。
恢复过程中最常见的风险是“配置看似恢复，实际依赖不可用”。例如应用启动成功，但外部 DNS 未切换；PVC 绑定成功，但数据版本不对；Secret 恢复成功，但证书已经过期。因此恢复验收不能只看 Pod Running，还要看业务请求、数据校验和用户影响。
演练清单：没有演练的备份不算可用
备份任务成功只能说明文件被生成，不能证明恢复有效。演练应尽量模拟真实故障，但要控制影响范围。常见方式包括在隔离集群恢复关键命名空间、抽样恢复单个业务、演练误删 PVC、验证跨区域拉起和检查 etcd 快照可用性。
一份实用的演练清单至少包含：
- 演练目标：验证哪个系统、哪类故障、哪个 RPO/RTO。
- 参与角色：平台、应用、数据库、安全和业务负责人。
- 恢复材料：备份文件、镜像、密钥、配置、Runbook 和审批记录。
- 验收指标：恢复耗时、数据完整性、接口可用性、告警恢复和日志连续性。
- 失败条件：超过 RTO、数据校验失败、关键依赖缺失或恢复步骤不可复现。
- 复盘输出：修复项、责任人、完成时间和下次演练范围。
演练频率可以按系统等级确定。核心系统建议至少按季度演练，重大版本升级、存储迁移、集群重构和灾备架构调整前应增加专项演练。
小结
Kubernetes备份恢复设计要从业务恢复目标出发，再拆到 etcd、声明式资源、应用数据和外部依赖。备份是否可用，最终要靠恢复演练证明，而不是靠任务成功率证明。对平台团队来说，最重要的是把恢复顺序、验证指标、失败条件和复盘机制写成可执行流程，并在真实变更前持续校准。
常见问题
1. 只备份 etcd 能恢复整个集群吗？
不能。etcd 能保存 Kubernetes API 对象状态，但应用数据库、持久卷、镜像仓库和外部依赖仍需单独备份和验证。
2. 备份恢复演练多久做一次？
建议至少按季度演练关键系统，重大版本升级、存储迁移和集群重构前也要做专项演练。低优先级系统可以降低频率，但仍应抽样验证恢复流程。
3. 恢复到新集群时最容易出什么问题？
常见问题包括存储类不一致、镜像拉取失败、Secret 缺失、LoadBalancer 地址变化、外部 DNS 未切换和应用启动顺序错误。
