Kubernetes 灾难恢复：来自三个可复现故障场景的指导
内容提要
备份不等于灾难恢复。三个可复现实验表明：备份完成不代表数据可用，需验证卷数据已迁移；GitOps仅恢复声明状态，存储数据须靠备份还原；多卷应用单独快照会产生时间偏差导致数据不一致，需用VolumeGroupSnapshot保证一致性。恢复测试应还原完整应用、校验数据并计时。
延伸解读
备份完成不等于数据可用
备份工具显示 Completed 只代表操作结束，不保证卷数据已迁移。文章建议检查 datauploads 的 BYTES 字段，确认实际字节数已写入外部存储。此外，备份工具不会自动保证数据库应用一致性，需要配置 flush 或 quiesce 钩子；恢复到不同基础设施时可能需调整存储类映射。只有端到端恢复测试才能证明应用能启动、数据正确并对外服务。
GitOps 恢复声明状态，备份恢复存储数据
GitOps 控制器能从 Git 重建 StatefulSet、Service 等声明，但会为 PVC 配置全新空卷，导致数据库运行却无数据。文章强调 Git 存储意图，备份存储状态，两者缺一不可。正确恢复流程是：先移除 GitOps 创建的空应用，再从备份还原包含卷数据的应用，最后校验数据。恢复可能跨基础设施，可移植性需测试而非假设。
多卷应用需 VolumeGroupSnapshot 保证一致性
单独快照多卷应用的不同卷会产生时间偏差，即使每个快照都 ReadyToUse，恢复后数据仍可能不一致。文章实验显示，间隔五秒快照两个卷导致 25 笔支付无对应订单。Kubernetes 1.36 的 VolumeGroupSnapshot 可协调多个 PVC 在同一时刻创建崩溃一致性恢复点。但需注意：支持普通 VolumeSnapshot 的驱动不一定支持组快照，且崩溃一致性不等于应用一致性，仍需 flush 或 quiesce。
恢复测试应还原完整应用并计时
恢复测试不是删除 Pod 看它重建，那只是测试工作负载协调。文章建议：将完整有状态应用还原到从未运行过它的干净目标；根据预期内容校验数据和用户路径，而非资源状态；用时钟测量整个过程。实验室中从断电到验证数据约四分钟，排练后不到两分钟，但生产 RTO 还需包含检测、决策、流量切换和回切。
Q&A
为什么说备份完成不等于灾难恢复？
备份完成只表示备份操作成功，并不证明应用能启动、包含预期数据或提供服务。只有端到端的恢复测试才能提供这种证据。
如何验证Kubernetes备份中确实包含了卷数据？
可以检查数据上传（DataUpload）的状态和已传输字节数，例如使用kubectl命令查看velero命名空间下的datauploads资源，确认PHASE为Completed且BYTES大于0。
GitOps能恢复存储数据吗？
不能。GitOps只恢复声明状态（如StatefulSet、Service等资源定义），存储数据必须通过备份工具从备份存储中还原。两者需要配合使用。
多卷应用单独快照会有什么问题？
单独快照不同卷会产生时间偏差，导致恢复后数据不一致。例如，一个卷的快照可能包含另一个卷尚未提交的数据，造成引用不存在的记录。
VolumeGroupSnapshot如何保证多卷一致性？
VolumeGroupSnapshot通过一个对象选择多个PVC，并向CSI驱动发送单个请求，在所有卷上创建协调的、崩溃一致的恢复点，从而消除跨卷时间偏差。
恢复测试应该怎么做？
恢复测试应：将完整的有状态应用恢复到从未运行过它的干净目标中；根据预期内容验证数据和用户路径，而非资源状态；并用时钟测量整个恢复过程。
