云原生备份与快照（Velero）

可视化演示

动态展示Velero备份执行流程、Cron定时调度、恢复拓扑排序与跨集群迁移机制。

现代架构演进

从前有一个大家庭，几代人挤在同一个祖宅里。家里的家具、族谱、粮食都放在一起，逢年过节只要请人把整个祖宅的东西装箱搬运一次，就算完成了“备份”。这正是传统单体架构的写照：一个应用包含所有功能，部署在一台服务器上，备份方式简单直接——整机复制即可。

如今，这个大家庭拆散了，各家各户搬进了一栋由 Kubernetes 物业公司管理的高层公寓。每户人家住在一个“容器”里，物业负责调度电梯、分配房间、处理住户流动。这带来一个麻烦：公寓社区里随时有住户搬进搬出，某个服务副本可能从 3 个缩到 1 个，存储卷可能被重新挂载。若还采用整屋复制的老办法，要么搬来一堆已无人居住的空房间，要么漏掉刚入住的新租户。备份的“完整性”因此成了第一要务——如同搬家前必须清点所有住户名单，而不是凭感觉塞几箱东西。

备份完整性的计算逻辑，本质上就是“实际搬走的家当”与“应该搬走的家当”之比：

回看公寓社区的比喻：一个负责任的搬迁公司必须拿着物业的住户总名单逐户核对，每搬走一家就在名单上打一个勾。打完勾后看一眼名单，那些没被勾掉的住户就是备份的缺口。

Velero 核心功能

应急搬迁公司正式入驻社区后，门口挂着一块招牌，写着三项主营业务：“备份、恢复、迁移”。这三项服务构成了 Velero 的核心功能：集群备份，把整个 K8s 集群的资源对象与数据卷打包归档；集群恢复，在集群损坏或误操作后把归档内容还原成可运行状态；集群迁移，把业务从一个集群原样搬到另一个集群，比如从自建机房搬到云上。

对用户来说，这家公司最诱人的地方是“免费开源”。它由云原生社区维护，依托 Kubernetes 原生的 API 机制工作，因此不需要在应用里嵌入任何代理代码。就像搬家公司不会要求每家每户改造房屋结构，只需要物业提供一份住户清单，就能完成所有搬运工作。

衡量这家公司服务好坏的关键指标，是“断电后多久能重新亮灯”，也就是恢复时间目标：

把应急搬迁公司想象成救火队：从火警响起到扑灭大火、住户重新入住，这段时间越短，社区损失越小。Velero 的价值，就是通过标准化的恢复流程把这段“救火时间”压缩到可控范围。

核心架构组件

如果我们要给应急搬迁公司画一张组织架构图，会看到四个关键角色。Velero Server 是总调度中心，运行在集群内，负责接收用户命令、编排备份与恢复任务；Node Agent（旧称 Velero Node Agent）是各楼栋的专属管家，它以 DaemonSet 方式驻留在每个节点上，随时准备配合执行数据备份；Restic 是搬家公司的那支“车队”，负责把存储卷里的文件逐一打包上传；对象存储则是城郊的大型仓库，用来长期存放所有备份包。

这四个角色各司其职：用户通过命令行告诉 Velero Server“今天要备份哪个命名空间”，Server 查询 Kubernetes API 获得资源清单，接着调度 Node Agent 启动 Restic 进程，Restic 把数据压缩加密后传送到对象存储桶。整个过程就像搬家公司在物业中心领到任务单，派遣楼栋管家和货车队协同作业。

备份过程会产生大量清单文件和日志文件，这些文件同样占用仓库空间，其整体大小可以估算为：

组织架构图里的每一份职责，最终都服务于一个简单目标：让“家当”安全抵达仓库。调度中心下发指令、楼栋管家确认现场、车队负责运输、仓库负责保管——缺少任何一个角色，备份链条就会断裂。

工作流程机制

一次标准的搬家流程是什么样的？首先，搬迁公司从物业处拿到住户总名单，逐一确认哪些房间需要搬、哪些可以跳过，这就是备份流程中的“资源发现”环节。接着，工人把每户的家具分别装箱，贴上标签打成 tar 包，对应 Velero 把每个命名空间的资源对象序列化归档。最后，车队将包裹运往郊区仓库，同时在仓库登记一份“货物清单”，方便日后查找。

为了让备份不会因遗忘而中断，Velero 提供了调度计划（Schedule）。用户只需说一句“每天晚上 2 点执行一次备份”，Velero 就会像闹钟一样准时启动任务，无需人工干预。仓库管理员还会关心包裹的存放期限，这就是 TTL（Time To Live）：备份包在对象存储里只保留指定天数，到期后自动清理，避免仓库被陈年旧货堆满。

一块备份包裹的“保质期”计算方式十分直观：

仓库的“保鲜期”机制保证了备份体系长期健康运转。没有 TTL 的备份仓库，就像从不清理杂物的地下室，总有一天会塞满无用的旧家具，真正需要空间存放新备份时反而无从下手。

快照与钩子

搬迁公司最怕什么？最怕住户的冰箱里还冻着海鲜，而搬家工人却要把冰箱拔掉电源。如果直接搬运，数据可能损坏。此时，专业的搬家公司会使用两种精细化手段：卷快照和钩子。

卷快照（Volume Snapshot） 相当于给冰箱拍一张“瞬时状态的 3D 照片”——不需要关机断电，就能在极短时间内记录磁盘的完整数据状态。Velero 可以通过云厂商的存储快照接口或 CSI 快照驱动完成这一操作，速度快、对业务影响小。备份钩子（Hooks）则像是搬家前的“电话确认”：Pre 钩子在备份前执行，告诉应用“请暂停写入，把内存数据刷到磁盘”；Post 钩子在备份完成后通知应用“可以继续正常工作了”，从而保证备份数据的一致性。

卷快照的耗时直接影响备份窗口，其计算公式为：

钩子和快照的组合，就像给冰箱搬家时既拍了保鲜照片，又提前打电话确认冰箱断电时间——每一个细节都是为了确保数据在“搬运中途”不丢失、不损坏。这也是 Velero 备份区别于简单文件拷贝的关键所在。

环境依赖配置

任何搬迁公司开张前，都需要先办齐“营业执照”。Velero 的第一张执照，是云厂商凭证——访问对象存储桶和创建卷快照所需的密钥。第二张执照是 Velero 安装，通常一条 velero install 命令即可完成，命令中需要指定 --provider（云厂商）、--bucket（存储桶名称）和 --secret-file（凭证文件路径）。第三张执照是备份存储桶，它是所有备份文件的最终归宿。第四张执照是 node-agent，它以 DaemonSet 形式在每个节点上运行，为 Restic 提供数据搬运能力。

配置齐备之后，一套可用的备份体系才算真正上线。如果缺少云厂商凭证，Velero 连仓库大门都进不去；如果没有指定存储桶，备份包无处安放；如果没有 node-agent，卷数据无法被读取上传。这就像搬家公司既没有货车，也没有仓库钥匙，自然寸步难行。

在实际的迁移工程中，我们常以“迁移完成率”来检查配置与执行是否到位：

“办执照”环节看似繁琐，却是整个备份体系的地基。很多新手在生产环境遇到的备份失败，最终排查下来都是凭证过期、存储桶权限不足或 node-agent 未启动——地基不稳，再豪华的搬家车队也无济于事。

异构云迁移

当公司决定从 A 城市搬到 B 城市，即从 AWS 迁到 GCP，或从自建机房迁到云上时，应急搬迁公司遇到了新挑战。跨云迁移时，最常见的坑是跨云快照不可用：AWS 的 EBS 快照无法在 GCP 上直接挂载，就像美国标准的电器插头插不进欧洲的插座。此时，卷快照方案普遍失效，必须退回到文件级备份——用 Restic 把文件逐个打包，再在目标集群重新组装成数据卷。这个过程更通用，但耗时更长。

Velero 的迁移流程通常是这样的：先在源集群执行一次完整备份（包含资源对象与卷数据），然后在目标集群执行 velero restore，把备份包中的内容还原出来。还原时还可以借助命名空间映射功能，把源集群的 ns-a 映射为 ns-b，避免命名冲突。最后一步是必不可少的备份验证：像搬完家后逐屋检查水电一样，工程师需要在目标集群上验证业务 Pod 能正常启动、数据库能正常读写。

跨云迁移最核心的指标是“最多会丢多少数据”，即恢复点目标：

搬家完成后，最重要的不是“东西都到了”，而是“每个东西都能正常使用”。跨云迁移的成功标准，从来不是备份文件复制完毕，而是业务在新城市继续运转如常。RPO 这个指标时刻提醒我们：备份越频繁，丢失的数据窗口越窄，迁移的保险系数越高。

AI 应用场景

Python 演示

class BackupAuditor:    """借助 Velero 备份清单统计信息，计算备份完整性指标。"""     def __init__(self):        self.policy_list = []   # 应备份的资源清单        self.done_list = []     # 实际备份成功的资源     def load_expected(self, items):        self.policy_list = list(items)     def load_backup(self, items):        self.done_list = list(items)     def complete_rate(self):        missing_map = {}        need_map = {}        names = set(list(self.policy_list) + list(self.done_list))        for k in names:            need_map[k] = self.policy_list.count(k)            missing_map[k] = max(0, need_map[k] - self.done_list.count(k))        total = sum(need_map.values())        miss = sum(missing_map.values())        return 100.0 * (total - miss) / total if total else 0.0  if __name__ == '__main__':    auditor = BackupAuditor()    auditor.load_expected(['deploy-api', 'svc-api', 'pvc-data', 'cm-config'])    auditor.load_backup(['deploy-api', 'pvc-data'])    print('备份完成率: %.1f%%' % auditor.complete_rate())

1. self.policy_list = []存储应备份资源的清单，相当于 Velero 查询 API 得到的资源总名单。
2. self.done_list = []记录实际备份成功的资源，对应 Velero 备份日志中的成功项。
3. load_expected` / `load_backup加载预期清单与真实备份结果，类似 velero backup describe 的输入数据。
4. need_map[k] = self.policy_list.count(k)统计每个资源在应备份清单中出现的次数，允许同名资源多副本存在。
5. missing_map[k] = max(0, need_map[k] - self.done_list.count(k))计算每个资源的缺失数量，防止同名资源被重复计数后出现负数。
6. 100.0 * (total - miss) / total if total else 0.0计算备份完整性百分比，如果清单为空则返回 0，避免除零错误。

常见误区

面试题