1. 课程导入与Velero定位

在 Kubernetes 生产环境中，备份与灾难恢复从来不是“装一个工具”就能解决的问题。集群里既有声明式 API 对象（Deployment、Service、ConfigMap、Secret、CRD 等），也有持久化数据（PV/PVC 背后的块存储或文件存储），还有承载整个控制面状态的 etcd。Velero 的价值，正是在这套分层体系里承担“Kubernetes 资源与卷数据的统一备份恢复编排者”角色，而不是替代 etcd 快照或存储快照。

理解 Velero 的定位，先要看清它到底操作什么。Velero 通过调用 Kubernetes API 读取资源对象，将其序列化为归档文件；对持久卷，则通过集成存储快照（CSI VolumeSnapshot）或 Restic/Kopia 文件级备份来复制数据。它把“资源清单 + 卷数据 + 备份元信息”打包成一份可迁移、可校验、可恢复的备份单元。这意味着 Velero 天然具备跨集群、跨命名空间、跨云迁移的能力，而 etcd 快照只能在同一控制面内整体还原。

从图中可以清晰看到三层分工：左侧是数据来源，中间是 Velero 的控制器编排，右侧是恢复目标场景。Velero 并不直接“复制 etcd”，也不直接“操作存储阵列”，它通过 Kubernetes API 和 CSI 接口完成资源与卷的协同备份。这正是它的能力边界：擅长应用级、命名空间级、跨集群的资源与数据编排；不擅长控制面级整体还原，也不替代底层存储的块级复制。

与 etcd 快照、存储快照的协作关系

etcd 快照保存的是整个集群的控制面状态，包括所有 API 对象、RBAC、CRD 定义等。它的优势是“全量、原子、控制面级”，适合集群整体故障后的同版本还原；局限是无法跨集群迁移、无法按命名空间粒度恢复、无法处理 PV 数据。Velero 则相反：它可以只备份某个命名空间、可以跨集群恢复、可以携带卷数据，但恢复的是“应用视角”的资源集合，不包含控制面自身的运行状态。

存储快照（CSI VolumeSnapshot）解决的是卷数据的一致性问题。Velero 在备份 PVC 时，如果集群支持 CSI 快照，会优先创建 VolumeSnapshot，再将快照内容备份到对象存储；如果不支持，则回退到 Restic/Kopia 做文件级复制。三者的协作关系可以概括为：etcd 快照保控制面，存储快照保卷一致性，Velero 保应用级可迁移恢复。生产环境中，三者通常同时存在，各自覆盖不同的故障域。

生产可靠性治理的整体视角

把 Velero 放进可靠性治理框架，需要关注四个维度：备份成功率、恢复成功率、RPO/RTO 达标率、备份存储健康度。备份成功率反映 Schedule 是否按时触发、VolumeSnapshot 是否创建成功、对象存储是否可写；恢复成功率反映备份数据是否可读、资源映射是否冲突、卷数据是否完整；RPO/RTO 则把“备份频率”和“恢复耗时”转化为可量化指标；备份存储健康度关注存储桶容量、生命周期策略、跨区域复制是否生效。

一个常见的生产误区是“备份任务显示 Completed 就认为万事大吉”。实际上，Velero 的 Backup 状态为 Completed 只代表归档写入成功，并不代表恢复时一定能成功。真正可靠的验证方式是定期执行恢复演练：在隔离命名空间或独立集群中执行 velero restore create，检查 Pod 是否 Running、PVC 是否 Bound、数据校验是否通过。只有恢复验证通过的备份，才算真正可用的备份。

在进入具体操作之前，建议先建立一张“故障域—恢复手段”对照表：控制面整体故障 → etcd 快照还原；命名空间误删 → Velero 资源恢复；PV 数据损坏 → 存储快照或 Velero 卷恢复；跨集群迁移 → Velero 备份 + 恢复。明确每种故障对应哪种手段，才能避免在真实故障发生时选错工具、错过恢复窗口。