企业官网建设流程全解析

Velero 插件异步操作进度监控（Plugin Progress Monitoring）设计全解析

【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero

导读：本文以 Velero 仓库中的设计文档 design/Implemented/general-progress-monitoring.md 为骨架，系统讲解 Velero 如何在备份/恢复流程中监控那些"执行后仍在后台运行"的插件操作——例如卷快照上传、数据搬运（data mover）等。读完本文，你将掌握 Velero 新增的WaitingForPluginOperations、Finalizing等备份/恢复阶段的状态机语义、OperationProgress/Progress/Cancel插件 API 的演进方式、<backup-name>-itemoperations.json.gz的持久化格式，以及这些设计在 pkg/controller、pkg/plugin/proto 等源码中的落地实现。

一、背景：为什么需要通用的异步操作监控

Volume Snapshotter 插件（卷快照插件）被 Velero 用来为持久卷内容创建快照。不同底层存储系统对"快照可用"的定义差异巨大：

• 有些存储系统的快照立即可用；
• 有些系统由插件在内部把快照上传到稳定存储后才可用；
• 还有些系统需要快照创建完成后由插件另行上传才可用。

Velero 的诉求是：一方面希望尽快推进备份流程的下一阶段，另一方面又不能把一个尚不可用的备份标记为 Completed——例如 AWS EBS 的快照虽然创建很快，但数据随后在后台转移到 S3，在持久化完成之前，该备份根本无法用于恢复。

除了卷快照之外，任何内部或第三方的 BackupItemAction（BIA）/RestoreItemAction（RIA）插件同样可能启动"不阻塞当前备份/恢复流程"的外部进程。典型场景包括：

• Data mover（数据搬运器）：在 BIA/RIA 内部执行的异步进程，通常针对特定 Kubernetes 资源（如 PVC），把数据搬运到 Velero 的 kopia/restic 实现之外的备份存储；
• 集群内镜像仓库的镜像备份/恢复：第三方插件也可复用该能力。

因此，这份设计（general-progress-monitoring.md）旨在替代此前只针对快照上传的 Upload Progress Monitoring 设计（见 design/upload-progress.md），把使用场景从"快照上传"扩展到"异步备份/恢复条目操作（Async Backup/Restore Item Actions）"，并把此前彼此独立的设计用例统一起来。

术语约定：BIA即 BackupItemAction，RIA即 RestoreItemAction。

典型场景示例

二、与原有 Upload Progress Monitoring 设计的核心差异

本设计最根本的变化是：不再提出新的专用 SnapshotItemAction 插件类型，而是修改现有 BackupItemAction 插件，使其可选地返回快照 ID（或其他条目操作 ID）。理由如下：

1. 设计范围已超出快照处理，需要在其他备份/恢复条目动作中同样支持异步操作；
2. Velero 1.10 已引入插件 API 版本化（plugin API versioning），此时修改现有插件 API 可行；
3. 备份和恢复两侧都需要该能力——若采用"新增插件类型"方案，则需要新增两个插件类型；
4. 除快照/操作 ID 返回外，其余插件处理逻辑与 BIA/RIA 完全一致；采用独立插件类型会导致附加条目处理等逻辑重复实现两遍。

另一个重大变化是：该机制同时应用于备份与恢复，虽然 Volume Snapshotter 用例只需要备份侧。这意味着备份阶段与工作流上的所有改动，恢复侧也需要对应实现。

术语上也做了泛化：不再使用snapshotID，统一为operationID（对卷快照器而言即快照 ID）。

三、目标与非目标

目标

• 监控备份/恢复条目动作中"快照完成之后仍继续执行"的操作；
• 防止不可用的备份/恢复（上传/持久化尚未完成等）被显示为已完成；
• 利用插件 API 版本化机制管理 BIA/RIA 接口变更；
• 让厂商能够基于 BIA/RIA 插件，把自有的 data mover 接入 Velero。

非目标

• 解决 Velero server 崩溃（Pod 被删除）时对进行中备份的恢复问题。当前 Velero 无法从崩溃中恢复进行中的备份，这会影响异步进程，但不在本设计范围内。

四、两种管理模型

内部配置与管理（Internal configuration and management）

快照向稳定存储的迁移由快照插件自行控制，决定"何时、迁移到哪里"不由 Velero 直接管理。这是当前 VolumeSnapshot 插件的模型。

Velero 控制的管理（Velero controlled management）

快照在 Velero 控制下被迁移到外部存储。这使 Velero 能够在存储系统之间搬运数据，也允许备份合作伙伴借助 Velero 先创建快照、再把数据搬入其自有备份仓库。从源码看，BackupSpec中的SnapshotMoveData、DataMover字段（见 pkg/apis/velero/v1/backup_types.go）正是为后一种模型预留的配置入口——DataMover为空或"velero"时使用内置 data mover。

五、备份与恢复阶段扩展（核心）

问题所在

当前 Velero 只有InProgress和Completed两个主阶段。备份在所有卷快照完成、Kubernetes 元数据写入对象存储后即进入Completed，但真实数据搬运可能仍在后台进行——备份在数据正确持久化之前并不真正稳定（如 AWS 场景，快照持久化前无法恢复）。

不过，快照创建完成后，只要后续备份/恢复不依赖尚未完成的备份，就可以并行推进。等待所有数据搬运完成再启动下一个备份只会拖慢系统进度，对用户没有实际收益。

新增阶段

因此设计引入了两个新阶段，用于备份和恢复：

• WaitingForPluginOperations：主流程（含快照创建）已成功完成，但快照上传或其他异步 BIA/RIA 插件操作仍在继续；
• WaitingForPluginOperationsPartiallyFailed：主流程已完成，但主流程或异步操作（含快照上传）中出现部分失败。

进入上述任一阶段后，Velero 就可以开始另一个备份/恢复。备份/恢复会停留在该阶段，直到所有 BIA/RIA 操作完成（例如卷快照数据全部成功迁移到持久存储）。一旦进入该阶段，备份/恢复就不会直接失败，但插件的错误返回可能使备份/恢复转入PartiallyFailed。若备份被删除（取消），插件会尝试删除快照并停止数据搬运——但并非所有存储系统都支持。

此外，仅备份（恢复没有）还新增两个阶段：

• Finalizing：所有异步备份操作成功完成，Velero 正在备份异步插件指示"操作完成后需要备份"的资源；完成后转入Completed；
• FinalizingPartiallyFailed：备份在初始处理或异步操作中出现错误，但异步操作已全部完成，Velero 正在备份后置资源；完成后转入PartiallyFailed。

Finalizing阶段最初只负责把异步操作执行期间可能变化的资源补录进备份，未来可扩展其他清理动作。

这些阶段在仓库类型定义中已完整落地，见 pkg/apis/velero/v1/backup_types.go（BackupPhase枚举）与 pkg/apis/velero/v1/restore_types.go（RestorePhase枚举）。

状态流转图

上图（仓库中的 design/Implemented/AsyncActionFSM.png）展示了备份/恢复从New出发的完整状态机。关键流转路径为：New→InProgress→ 进入WaitingForPluginOperations/WaitingForPluginOperationsPartiallyFailed（存在未完成的异步操作）→ 全部完成后转入Finalizing/FinalizingPartiallyFailed（仅备份）→ 最终抵达Completed/PartiallyFailed/Failed等终止态。

各阶段语义详解

New：备份/恢复请求刚创建。下一状态是InProgress或FailedValidation。

FailedValidation：请求格式错误，进入该阶段并终止。

InProgress：开始执行。保持在该阶段直到所有 pre/post 执行钩子完成、所有快照创建完成、Kubernetes 元数据与备份/恢复信息安全写入对象存储插件。当前实现中，Restic 备份的数据搬运发生在InProgress阶段；未来可将快照与 Restic（或等价）备份结合，让数据搬运在WaitingForPluginOperations阶段完成。

InProgress之后，按有无未完成异步操作与是否出现错误，分别进入：

• 有未完成异步操作、无错误 →WaitingForPluginOperations；
• 有未完成异步操作、至少一个错误 →WaitingForPluginOperationsPartiallyFailed；
• 恢复无未完成操作、无错误 →Completed；
• 恢复无未完成操作、有错误 →PartiallyFailed；
• 备份无未完成操作、无错误 →Finalizing；
• 备份无未完成操作、有错误 →FinalizingPartiallyFailed。

最终阶段本应为Completed或PartiallyFailed的备份/恢复，也可能先进入WaitingForPluginOperations系列阶段。注定Failed的备份/恢复直接进入Failed阶段。Failed 备份创建的快照仍可能在后台继续上传，但不再被监控或更新；若备份进入Failed时仍有进行中的操作（按当前工作流不应发生），应对这些操作调用Cancel()。删除Failed备份时，所有快照会被删除，仍在进行中的上传应被中止。

WaitingForPluginOperations：主流程（含快照创建）成功完成，上传及其他异步 BIA/RIA 操作继续。此阶段出错则转入WaitingForPluginOperationsPartiallyFailed；成功则备份转入Finalizing、恢复转入Completed。该状态下备份不可用于恢复。

WaitingForPluginOperationsPartiallyFailed：主流程完成，但主流程或异步操作（含快照上传）存在部分失败。该状态下备份不可用于恢复。

Finalizing：异步备份操作全部成功完成，Velero 正在备份异步插件指示的后置资源；完成后转入Completed。该状态下备份不可用于恢复。

FinalizingPartiallyFailed：备份初始处理或异步操作曾出错，但异步操作已全部完成，Velero 正在备份后置资源；完成后转入PartiallyFailed。该状态下备份不可用于恢复。

Failed：出现致命错误。该状态下的备份不可用于恢复。

Completed：备份/恢复完成，所有数据已转移到稳定存储（或恢复到集群），任何处于该状态的备份都可安全用于恢复；达到Completed后即可安全删除已备份的条目。

PartiallyFailed：备份/恢复已完成，但至少部分可用。从PartiallyFailed备份恢复不会得到完整恢复，但可能取回部分内容。

六、工作流总览

1. 执行备份或恢复动作时，各 BIA、RIA 或 VolumeSnapshot 插件返回操作 ID（快照 ID 或其他插件特定标识符）。插件应能报告快照进度，并在快照被删除时处理操作/上传的取消；插件重启后操作 ID 仍应有效。
2. 所有快照创建完成、Kubernetes 资源持久化到 ObjectStore 插件后，备份要么存在致命错误，要么至少部分可用。
3. 存在致命错误 → 进入Failed并结束。备份/恢复失败时，上传或其他操作不会取消，但也不再被监控。任何阶段下的备份被删除时，所有快照都会被删除；VolumeSnapshotter.DeleteSnapshot或DeleteItemAction.Execute被调用时，插件会取消数据搬运及其他操作、移除快照与关联资源。
4. 备份/恢复离开InProgress阶段且无致命错误时，Velero 开始轮询插件查询操作状态。
5. 若有操作未完成 → 进入WaitingForPluginOperations/WaitingForPluginOperationsPartiallyFailed/Failed。
6. 快照后操作可能耗时很长，期间 Velero 与插件可能重启。一旦进入WaitingForPluginOperations系列阶段，即可启动另一个备份/恢复。
7. 在WaitingForPluginOperations系列阶段中，快照与条目动作被周期性轮询。全部成功上报后，恢复直接进入Completed/PartiallyFailed；备份进入Finalizing/FinalizingPartiallyFailed（取决于此前所处阶段）。
8. 在Finalizing系列阶段，Velero 把插件指示的"操作完成后需加入备份"的资源更新进备份，然后按是否有备份错误进入Completed/PartiallyFailed。
9. 备份资源在离开InProgress阶段时写入对象存储，但在进入终止阶段（Completed/Failed/PartiallyFailed）之前不会同步到其他集群（当前集群也不可用于恢复）。Finalizing阶段会以异步插件所需资源更新备份资源。

InProgress 备份的对账

InProgress备份在对象存储中没有velero-backup.json。对账过程中，缺少该对象的备份会被忽略——这与 pkg/controller/backup_sync_controller.go 中按对象存储状态进行备份同步的逻辑相互印证。

七、插件 API 变更

OperationProgress 结构体

设计文档给出的核心数据结构如下，插件通过Progress方法返回它：

type OperationProgress struct { Completed bool // 操作已完成（成功或失败）时为 true Err string // 操作失败时设置 NCompleted, NTotal int64 // 已完成的量与该操作的总量（单位见 OperationUnits） // 对 data mover 与卷快照器场景，单位为字节 // 成功完成时 completed 与 total 应相等 OperationUnits string // completed/total 所代表的单位——对 data mover 与条目快照器，通常为字节 Description string // 操作进度的可选描述 Started, Updated time.Time // 上传开始时间与最后一次更新时间。并非所有系统 // 都保留开始时间，未知时返回 Time 0（time.Unix(0, 0)） }

该结构在 gRPC 层面对应有OperationProgress消息，字段为completed / err / nCompleted / nTotal / operationUnits / description / started / updated，见 pkg/plugin/proto/Shared.proto。

VolumeSnapshotter 接口变更

新增两个方法：

Progress(snapshotID string) (OperationProgress, error) Cancel(snapshotID string) (error)

• Progress报告快照上传的当前状态，快照创建后的任何时间都可调用；插件重启后，只要 operationID（快照 ID）仍有效，就应能获取进度。
• error在获取进度出现问题时设置；若快照在上传期间出错，错误应通过OperationProgress返回而error应为 nil。

BackupItemAction 接口变更

新增Name()、Progress(operationID string, backup *api.Backup) (velero.OperationProgress, error)、Cancel(operationID string, backup *api.Backup) error三个方法，并修改Execute()返回签名：

// Name 返回该 BIA 的名称。实现该接口的插件必须定义 Name， // 但其内容不重要——不会真的通过 RPC 调用。Velero 的插件基础设施 // 会直接实现该方法（而非委托给 RPC 插件），以返回插件注册时的名称。 Name() string // Execute 允许 BackupItemAction 对被备份条目执行任意逻辑（含在备份前修改条目）。 // 应返回条目（未修改或已修改），以及一个可选的 ResourceIdentifiers 切片（指定现在 // 就要备份的附加相关条目）、一个可选的 operationID（用于启动异步动作的动作）、 // 以及第二个 ResourceIdentifiers 切片（指定所有异步操作完成后需要备份的相关条目）。 // 最后一个字段在 operationID 为空时被忽略；且仅当资源必须在异步操作完成后 // 更新进备份（即异步操作期间会更新该条目在恢复时所需的某些 Kubernetes 元数据）时 // 才应填写。 Execute(item runtime.Unstructured, backup *api.Backup) (runtime.Unstructured, []velero.ResourceIdentifier, string, []velero.ResourceIdentifier, error) // Progress Progress(operationID string, backup *api.Backup) (velero.OperationProgress, error) // Cancel Cancel(operationID string, backup *api.Backup) error

这些变更在 v2 插件协议中已经落地：ExecuteResponse包含item / additionalItems / operationID / postOperationItems四个字段，服务定义新增Progress与Cancel两个 RPC，见 pkg/plugin/proto/backupitemaction/v2/BackupItemAction.proto。

RestoreItemAction 接口变更

同样新增Name()、Progress、Cancel，并修改Execute输出结构：

// Execute 允许 ItemAction 对被恢复条目执行任意逻辑（含恢复前修改条目）。 // 应返回条目（未修改或已修改）、可选的 OperationID、可选的 ResourceIdentifiers 切片 //（指定需要恢复的附加相关条目）、以及一个 warning（仅记录日志、不阻止条目恢复） // 或 error（记录日志并阻止条目恢复）。若指定了 OperationID， // 则 Velero 会等待该操作完成，恢复才会被标记为 Completed。 Execute(input *RestoreItemActionExecuteInput) (*RestoreItemActionExecuteOutput, error) // Progress Progress(operationID string, restore *api.Restore) (velero.OperationProgress, error) // Cancel Cancel(operationID string, restore *api.Restore) error // RestoreItemActionExecuteOutput 包含 ItemAction 执行函数的输出变量。 type RestoreItemActionExecuteOutput struct { // UpdatedItem 是被 ItemAction 修改后待恢复的条目。 UpdatedItem runtime.Unstructured // AdditionalItems 是需要恢复的附加相关条目列表。 AdditionalItems []ResourceIdentifier // SkipRestore 告诉 Velero 停止对该条目执行后续动作并跳过恢复步骤。 // 为 true 时 AdditionalItems 被忽略。 SkipRestore bool // OperationID 是标识异步动作正在进行的标识符，Velero 会在恢复该条目后继续监控它。 // 为空则表示没有进行中的操作。 OperationID string }

对应协议见 pkg/plugin/proto/restoreitemaction/v2/RestoreItemAction.proto。

Cancel 与错误语义

• Velero 可调用 BIA/RIA 的Cancel尝试取消操作，插件可据此采取适当动作。Cancel会在备份删除以及可能超时时对未完成操作调用；它不用于删除已完成动作的结果，对已完成动作无效果。除标准 Error 返回值外Cancel无返回值，该 Error 只用于意外失败——正常情形下Cancel直接返回 nil error，无论插件是否真的取消了操作。
• _AsyncOperationsNotSupportedError_只应由Progress返回，表示该 BIA/RIA 插件本不应处理该条目；若插件应处理条目但（例如）找不到条目/快照 ID 来报告进度，Progress应返回InvalidOperationIDError而非填充好的OperationProgress。条目动作未启动异步操作时，operationID 为空。

八、备份格式变化与itemoperations.json.gz

本设计不改变现有备份格式，但随备份工作流新增一个<backup-name>-itemoperations.json.gz文件，其中包含 VolumeSnapshotter 与 BackupItemAction 插件返回的条目及操作 ID（快照 ID）。同时，velero-backup.json的创建推迟到备份进入终止阶段（Completed/PartiallyFailed/Failed）；对账逻辑应忽略没有velero-backup.json对象的备份。

该文件中存储 BIA/RIA 插件标识符、ItemID 与 OperationID；查询进度时用这些信息选择正确的插件。设计文档给出的 data mover 插件记录示例：

{ "spec": { "backupName": "backup-1", "backupUID": "f8c72709-0f73-46e1-a071-116bc4a76b07", "backupItemAction": "velero.io/volumesnapshotcontent-backup", "resourceIdentifier": { "Group": "snapshot.storage.k8s.io", "Resource": "VolumeSnapshotContent", "Namespace": "my-app", "Name": "my-volume-vsc" }, "operationID": "<DataMoverBackup objectReference>", "itemsToUpdate": [ { "Group": "velero.io", "Resource": "VolumeSnapshotBackup", "Namespace": "my-app", "Name": "vsb-1" } ] }, "status": { "operationPhase": "Completed", "error": "", "nCompleted": 12345, "nTotal": 12345, "operationUnits": "byte", "description": "", "Created": "2022-12-14T12:00:00Z", "Started": "2022-12-14T12:01:00Z", "Updated": "2022-12-14T12:11:02Z" } }

该结构与仓库中 pkg/itemoperation/backup_operation.go 的BackupOperationSpec（backupName、backupUID、backupItemAction、resourceIdentifier、operationID、postOperationItems）一一对应，说明设计文档中的示例在实现时被建模为BackupOperation对象。该文件在处理完备份所有条目之后、阶段离开InProgress之前上传到对象存储；存储层实现可参见 pkg/persistence/object_store.go 与 pkg/persistence/object_store_layout.go。

恢复侧对应文件

恢复同样新增<restore-name>-itemoperations.json.gz，包含 RestoreItemAction 返回的条目与操作 ID，格式与备份侧一致，也在处理完所有条目后、离开InProgress前上传。

边界情况

• 创建备份的集群在备份完成前保有 Backup 资源并可管理它；
• 若 Backup 资源在备份完成、写入velero-backup.json之前被移除（如卸载 Velero），对象存储中的其他对象将被孤儿化。当前版本也可能发生，但时间窗口小得多。

九、实际应用：CSI 快照与 vSphere 插件

• CSI 快照：像 EBS 这类系统，快照要等存储系统转移到稳定存储后才可用。CSI 快照通过readyToUse状态暴露这一信息（对 EBS 而言表示快照已转移到持久存储、可以使用）。CSI BackupItemAction 的Progress方法轮询该字段，完成后返回完成。仓库中的实现位于 pkg/backup/actions/csi（如 volumesnapshotcontent_action.go、volumesnapshot_action.go、pvc_action.go），恢复侧的 CSI 动作见 pkg/restore/actions/csi。
• vSphere 插件：vSphere Plugin for Velero 在后台把快照上传到 S3。它同样是 BackupItemAction 插件，会检查快照的 Upload 记录状态并返回进度。

十、备份工作流变化

备份工作流在"写入velero-backup.json"之前保持不变。此后：

1. Velero 遍历所有 VolumeSnapshotter/BIA 操作，逐一调用Progress；
2. 若所有备份条目操作都已结束（成功或失败）→ 备份进入对应 finalize 阶段；
3. 若仍有快照或备份条目在处理中 → 备份阶段设为WaitingForPluginOperations/WaitingForPluginOperationsPartiallyFailed，由异步备份操作控制器周期性对账并调用未完成操作的Progress；任一进度检查返回错误，阶段转入WaitingForPluginOperationsPartiallyFailed；
4. 所有操作完成后 → 备份进入 finalize 阶段，备份 finalizer 控制器用异步操作完成后所需资源更新对象存储中的velero-backup.json，随后备份进入对应终止阶段。

以上流程在源码中的落点即 pkg/controller/backup_operations_controller.go：该 reconciler 通过PeriodicalEnqueueSource周期性入队WaitingForPluginOperations/WaitingForPluginOperationsPartiallyFailed状态的备份，默认轮询频率为 10 秒（defaultBackupOperationsFrequency = 10 * time.Second）。getBackupItemOperationProgress会遍历每条BackupOperation，通过GetBackupItemActionV2获取插件并调用Progress，同步NCompleted/NTotal/OperationUnits/Description/Started/Updated等字段；操作超过backup.Spec.ItemOperationTimeout（默认 4 小时，见 pkg/apis/velero/v1/backup_types.go）后调用Cancel并标记为超时失败；全部完成后备份转入Finalizing/FinalizingPartiallyFailed。

十一、恢复工作流变化

恢复工作流在 Velero 原本要把恢复移入终止状态时发生变化：

1. Velero 遍历所有 RestoreItemAction 操作，逐一调用Progress；
2. 若所有恢复条目操作都已结束 → 恢复完成，进入对应终止阶段；
3. 若有条目仍处理中 → 阶段设为WaitingForPluginOperations/WaitingForPluginOperationsPartiallyFailed，由异步恢复操作控制器周期性对账并调用Progress；任一进度检查出错则转入WaitingForPluginOperationsPartiallyFailed；全部完成后恢复进入对应终止阶段。

对应实现见 pkg/controller/restore_operations_controller.go，条目操作模型见 pkg/itemoperation/restore_operation.go。

十二、重启工作流

Velero server 重启后：

• 扫描所有 Backup/Restore 资源；
• 处于InProgress阶段的备份/恢复 → 移入Failed阶段；
• 处于WaitingForPluginOperations/WaitingForPluginOperationsPartiallyFailed阶段的 → 视为已重新入队，检查进度，并按结果重新入队或移入终止阶段。

重启恢复能力的根基在于：itemoperations文件在离开InProgress阶段前已写入对象存储，Progress调用依据其中的插件标识符与 operationID 重建监控上下文——这也是 pkg/itemoperationmap（BackupItemOperationsMap/RestoreItemOperationsMap）从对象存储读取操作列表、再通过backupStoreGetter获取存储句柄的实现动机。

十三、对已合并代码的更新说明

由于本设计修改了此前已批准的设计，下列基于旧 Upload Progress Monitoring 的准备工作可能需要调整：

1. 已定义的Uploading/UploadingPartiallyFailed阶段常量，在定义新阶段时需移除；
2. 移除 ItemSnapshotter 插件 API 及其相关代码——修订版设计复用 VolumeSnapshotter 与 BackupItemAction 插件；
3. UploadProgressFeatureFlag不再需要——新功能加入 VolumeSnapshotter、BIA、RIA 插件的V2版本，且仅在存在返回操作 ID 的插件时才被使用；
4. 为备份新增<backup-name>-itemsnapshots.gz文件（如有）仍属于修订版设计的一部分，应保留；
5. 旧设计对应的实现 PR（Upload Progress Monitoring 与 Item Snapshotter 基础支持）尚未合并，无需回滚，但其实现思路可为新设计提供参考（其设计提案已发生多处变化）。

十四、实现任务清单

设计文档最后列出的落地任务包括：

• VolumeSnapshotter 新插件 API；
• BackupItemAction 新插件 API；
• RestoreItemAction 新插件 API；
• 新备份阶段；
• 新恢复阶段；
• 延迟上传velero-backup.json；
• AWS EBS 插件Progress实现；
• 操作监控；
• <backup-name>-itemoperations.json.gz实现；
• <restore-name>-itemoperations.json.gz实现；
• 重启逻辑；
• 对账逻辑改为忽略未完成的备份/恢复；
• CSI 插件 BackupItemActionProgress实现；
• vSphere 插件 BackupItemActionProgress实现（由 vSphere 插件团队负责）。

从当前仓库代码看，以上绝大部分任务均已落地：阶段定义（backup_types.go、restore_types.go）、v2 插件协议（pkg/plugin/proto）、异步操作控制器（backup_operations_controller.go、restore_operations_controller.go）、条目操作持久化（pkg/itemoperation、pkg/itemoperationmap）等均有对应源码与测试（如 backup_operations_controller_test.go、restore_operations_controller_test.go）。

十五、开放问题

设计文档保留了两个待定问题，理解实现时值得留意：

1. VolumeSnapshotter 是否需要Cancel操作？从反馈看很可能不需要——Cancel的唯一实际作用是告知插件"Velero 不再等待"，若有必需的自定义取消动作可借此执行；对已在进行的快照上传而言，没有更多可取消的内容。
2. 是否应在进入WaitingForPluginOperations/WaitingForPluginOperationsPartiallyFailed阶段之前（而非等所有操作完成之后）就写入备份？相关操作不会影响写入对象存储的备份内容，且等待中的操作列表已写入对象存储；提前写入备份可让 Velero 在该阶段重启时更具韧性。

这两点也从侧面印证了该设计"以状态机驱动异步插件操作生命周期"的核心思想：让备份/恢复尽早释放主流程，同时用可持久化、可轮询、可取消的操作记录来严格守护"备份真正可用"的边界。

【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero