Velero Block Data Mover 设计解析：基于 CBT 的块级备份/恢复架构与实现

Velero Block Data Mover 设计解析基于 CBT 的块级备份/恢复架构与实现【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero块级数据移动是 Velero 在 CSI 快照数据移动Volume Snapshot Data Movement之上推出的重要能力它借助 Kubernetes Change Block TrackingCBTAPI 与 Kopia 仓库的增量感知扩展让块存储卷只传输真实变化的数据从而显著降低网络、仓库与备份存储的开销。本文以仓库内 设计文档 为骨架结合 Unified Repository 设计、Volume Snapshot Data Movement 设计 与当前源码实现系统讲解块数据移动器的架构、数据路径、CBT 层、增量仓库扩展、CRD 与 CLI 变更帮助你理解 Velero 如何在文件系统级备份之外提供更高效、更低 TCO 的块级备份/恢复方案。背景为什么需要块级备份/恢复Kubernetes 的持久卷有两种卷模式FileSystem与Block。底层存储既可以用块存储来提供这两种模式的卷也可以用文件存储来提供FileSystem模式卷。由此引出一个基本事实由块存储提供的卷无论卷模式是FileSystem还是Block都可以从块层面进行备份/恢复只要数据能从文件系统访问就可以从文件系统层面备份/恢复即FileSystem模式卷无论底层存储类型如何都能走文件系统级备份当FileSystem模式卷由块存储提供时两种备份方式都可用。Velero 现有的 CSI 快照数据移动由 VBDM 实现只内置了文件系统上传器因此备份/恢复全部发生在文件系统层面。而一旦条件允许块级备份/恢复相比文件系统级有着明确优势可借助 CBT 只处理最小数据量大幅降低对网络、备份仓库和备份存储的开销从而显著降低 TCO总拥有成本吞吐与资源消耗更优无需处理文件系统的复杂度尤其适合文件系统内存在海量小文件的场景对操作系统依赖更少上传器无需操作系统感知卷内的文件系统。设计文档写作时Kubernetes CBT API 已趋于成熟并接近 Beta许多平台/存储厂商已经或即将支持。因此 Velero 需要交付块级备份/恢复并在满足以下条件时推荐用户优先于文件系统数据移动器使用卷由块存储提供块级访问可行平台支持 CBT。同时文件系统级备份/恢复在以下场景依然有价值卷由文件存储提供如 AWS EFS、Azure File、CephFS 等卷由块存储提供但 CBT 不可用卷不支持 CSI 快照而只能使用 Velero PodVolume Backup。设计上块数据移动器应基于 VGDP、VBDM 与 VGDP 微服务构建以复用这些模块已有的丰富能力并发、节点选择、缓存卷、去重、压缩、加密等。两个需要说明的平台限制VBDM 同时支持 Linux 与 Windows 节点但 Windows 容器不支持块模式卷因此在 Windows 容器移除该限制前无法从 Windows 节点进行块级备份/恢复集群同时存在 Linux 与 Windows 节点时块数据移动器只能运行在 Linux 节点Kubernetes CBT 服务与 Velero 都运行在集群边界内即使后端存储被多个集群共享Velero 也只能保护其所在集群的工作负载。目标与非目标设计目标聚焦于为 CSI 快照数据移动 增加块数据移动器支持FileSystem与Block两种模式卷的块级全量备份支持两种模式卷的块级增量备份支持从全量/增量备份进行块级恢复两种卷模式支持从 Linux 集群节点对 Linux 与 Windows 工作负载进行块级备份/恢复支持既有特性负载并发、节点选择、缓存卷、去重、压缩、加密等支持同一备份/恢复中同时存在文件系统级与块级处理的卷。非目标同样明确PodVolume Backup 只做文件系统级备份/恢复不支持块级由文件存储提供的卷只能走文件系统级备份/恢复不支持从 Windows 节点备份/恢复块级增量备份对备份仓库有特殊能力要求而 Velero Unified Repository 支持多种仓库当前设计只聚焦 Kopia 仓库其他仓库的块级增量备份将在其接入 Unified Repository 后再考虑。总体架构与数据路径块数据移动器并非另起炉灶而是基于现有 VBDM 增量改造。下图展示了 VGDP 集成到 Unified Repository由 Kopia 仓库实现后的数据路径架构在 VGDP 中一个新的块数据移动器被添加在既有文件系统数据移动器旁边两者通过 Unified Repo 接口对同一个备份仓库进行读写同时Unified Repo 接口与备份仓库需要增强以支持增量备份。关于 VGDP 的更多细节可参考 Unified Repository 设计、Volume Snapshot Data Movement 设计 与 VGDP 微服务设计。备份架构备份架构复用了现有 VBDM主要变化点有四个Exposer无论源 PVC 的模式如何始终创建块模式的 backupPVCCBT 层新增的层次负责检索、转换与存储变化块通过 gRPC 与 CSI SnapshotMetadataService 交互Uploader新增块上传器与 CBT 层交互持有从块设备高效读数据以及向 Unified Repository 增量写数据的专用逻辑扩展 Kopia 仓库在 Kopia 的 CAOS 之上新增增量感知对象扩展Incremental Aware Object Extension以支持增量写Kopia 仓库的其他部分既有 CAOS 与 CABS保持不变。恢复架构恢复同样复用 VBDM主要变化点Exposer当 restorePV 为块模式时需要把 restorePV 重新绑定rebind到目标 PVC目标 PVC 既可以是文件系统模式也可以是块模式Uploader同一个块上传器持有高效写块设备、以及从 Unified Repository 备份链读取数据的专用逻辑。数据移动器类型选择每次备份的选择Per Backup Selection当前备份接受一个DataMover参数当值为空或velero时使用 VBDM。引入块数据移动器后VBDM 将包含两种类型Velero 文件系统数据移动器与 Velero 块数据移动器。设计引入了两个新取值velero-block使用 Velero 块数据移动器velero-fs使用 Velero 文件系统数据移动器。为向后兼容velero仍是合法值它表示默认数据移动器默认值可以在不同发行版之间变化当前默认是 Velero 文件系统数据移动器未来可切换为 Velero 块数据移动器。这些取值在源码中已有对应定义见 pkg/util/datamover/datamover.goDataMoverTypeVeleroFs velero-fs、DataMoverTypeVeleroBlock velero-block以及 pkg/uploader/types.go 中的BlockType velero-block常量。通过 Volume Policy 进行逐卷选择实际场景中用户可能在一次备份里希望部分卷走文件系统数据移动器、另一部分卷走块数据移动器。为此设计采用每次备份选择 Volume Policy的组合方案。VolumePolicy 的核心数据结构如下与 internal/resourcepolicies 中实现对应type volPolicy struct { action Action conditions []volumeCondition } type volumeCondition interface { match(v *structuredVolume) bool validate() error } type structuredVolume struct { capacity resource.Quantity storageClass string nfs *nFSVolumeSource csi *csiVolumeSource volumeType SupportedVolume pvcLabels map[string]string pvcPhase string } type Action struct { Type VolumeActionType yaml:type Parameters map[string]any yaml:parameters,omitempty } const ( ConfigmapRefType string configmap Skip VolumeActionType skip FSBackup VolumeActionType fs-backup Snapshot VolumeActionType snapshot )action.parameters用来提供动作的额外信息恰好适合区分 Velero 文件系统与块数据移动器。Velero 内置数据移动器支持在parameters中携带dataMover键取值velero-fs或velero-block含义与每次备份选择一致。使用示例一次备份中同时使用velero-block与velero-fs——备份的DataMover参数设置为velero-block在 Volume Policy 中增加一条记录用conditions过滤希望走文件系统数据移动器的卷action.type设为snapshot并在action.parameter中加入dataMover:velero-fs。这样所有被conditions匹配的卷将使用 Velero 文件系统数据移动器其余卷回退到备份级选择的 Velero 块数据移动器。反之亦可将备份级方法设为文件系统数据移动器再为部分卷选择块数据移动器。每个卷最终选用的数据移动器需要记录到volumeInfo.json中。控制器与 Exposer控制器Backup 控制器与 Restore 控制器保持不变仍然通过异步操作async operations与 VBDM 交互。DataUpload 控制器与 DataDownload 控制器基本保持不变仅做少量修改以正确处理数据移动器类型与备份类型并将其传递给 exposer。得益于 VGDP 微服务 的设计控制器与 VGDP 几乎解耦因此无需大改。相关控制器的现有实现可参考 pkg/controller 与 pkg/controller。CSI Snapshot Exposer复用现有 CSI Snapshot Exposer但需按访问模式决定 backupPVC 的卷模式。对 Velero 块数据移动器访问模式恒为Block因此 backupPVC 的卷模式恒为Block。backupPVC 以正确的卷模式创建后现有代码即可正确地创建 backupPod 并挂载 backupPVC。实现位于 pkg/exposer/csi_snapshot.go。Generic Restore Exposer 与重新绑定流程复用现有 Generic Restore Exposer但工作流需要调整。对块数据移动器restorePV 始终是块模式而目标 PVC 可能是文件系统模式或块模式。Kubernetes 不允许将 PV 绑定到卷模式不匹配的 PVC 上。因此Volume Snapshot Data Movement 设计 中介绍的Finish Volume Readiness工作流被修改为恢复完成、restorePV 创建后将 restorePV 的deletionPolicy设为Retain创建另一个 rebindPV复制 restorePV 的volumeHandle但volumeMode与目标 PVC 匹配删除 restorePV将 rebindPV 的claimRef字段指向目标 PVC给 rebindPV 打上velero.io/dynamic-pv-restore标签。这样目标 PVC 会被 Kubernetes 立即绑定到 rebindPV。该新流程对文件系统数据移动器同样有效因此旧流程将被替换只保留新流程。相关实现可参考 pkg/exposer/generic_restore.go。VGDP 与 Unified Repo 的增量能力增强块数据移动器下每个卷对应一个 Unified Repo 对象并伴随保存描述卷的元数据。备份写入采用可跳过写skippable-write方式对不跳过的数据区间以真实数据写入对象对被跳过的区间数据要么填 ZERO、要么从父对象克隆。具体地全量备份填 ZERO增量备份从父对象克隆。ObjectWriter 接口扩展为支持可跳过写ObjectWriter接口需要扩展以支持io.WriterAt。当前仓库中 pkg/repository/udmrepo/repo.go 已实现该接口type ObjectWriter interface { // Write writes data to the object in the sequential manner. Write([]byte) (int, error) // WriterAt is used in the cases that the object is not written sequentially. WriteAt([]byte, int64) (int, error) // Checkpoint is periodically called to preserve the state of data written to the repo so far. // Checkpoint returns a unified identifier that represent the current state. // An empty ID could be returned on success if the backup repository doesnt support this. Checkpoint() (ID, error) // Result waits for the completion of the object write. // Result returns the objects unified identifier after the write completes. Result() (ID, error) // Close closes the object writer and releases all resources. Close() error }ObjectWriteOptions 扩展要从父对象克隆数据调用方需要指定父对象因此ObjectWriteOptions增加了ParentObject字段既有AccessMode用于指示数据访问类型文件系统或块。仓库 pkg/repository/udmrepo/repo.go 中的完整定义如下// Below consts describes the data type of one object. // Metadata: This type describes how the data is organized. // For a file system backup, the Metadata describes a Dir or File. // For a block backup, the Metadata describes a Disk and its incremental link. ObjectDataTypeUnknown int 0 ObjectDataTypeMetadata int 1 ObjectDataTypeData int 2 // Below consts defines the access mode when creating an object for write ObjectDataAccessModeUnknown int 0 ObjectDataAccessModeFile int 1 ObjectDataAccessModeBlock int 2 ObjectDataBackupModeUnknown int 0 ObjectDataBackupModeFull int 1 ObjectDataBackupModeInc int 2 // ObjectWriteOptions defines the options when creating an object for write type ObjectWriteOptions struct { FullPath string // Full logical path of the object DataType int // OBJECT_DATA_TYPE_* Description string // A description of the object, could be empty Prefix ID // A prefix of the name used to save the object AccessMode int // OBJECT_DATA_ACCESS_* BackupMode int // OBJECT_DATA_BACKUP_* AsyncWrites int // Num of async writes for the object, 0 means no async write ParentObject ID // The object in the previous snapshot, for incremental backup }BackupRepo 接口扩展为了让非 Kopia 上传器也能把快照与元数据保存到 Unified RepoBackupRepo接口增加了快照相关方法与元数据相关方法均已在 pkg/repository/udmrepo/repo.go 落地// SaveSnapshot saves a repo snapshot SaveSnapshot(ctx context.Context, snapshot Snapshot) (ID, error) // GetSnapshot returns a repo snapshot from snapshot ID GetSnapshot(ctx context.Context, id ID) (Snapshot, error) // DeleteSnapshot deletes a repo snapshot DeleteSnapshot(ctx context.Context, id ID) error // ListSnapshot lists all snapshots in repo for the given source ListSnapshot(ctx context.Context, source string) ([]Snapshot, error) // WriteMetadata writes metadata to the repo, metadata is used to describe data, e.g., file system // dirs are saved as metadata WriteMetadata(ctx context.Context, meta *Metadata, opt ObjectWriteOptions) (ID, error) // ReadMetadata reads a metadata from repo by the metadatas object ID ReadMetadata(ctx context.Context, id ID) (*Metadata, error)Unified Repo 的 kopia-lib 通过调用对应的 Kopia 仓库函数实现这些接口。在 pkg/repository/udmrepo/kopialib/lib_repo.go 中可以看到当opt.AccessMode udmrepo.ObjectDataAccessModeBlock时NewObjectWriter返回增量感知的kopiaObjectWriterEx实现它支持WriteAt、Checkpoint、异步写入与错误面向上层暴露同文件的测试 pkg/repository/udmrepo/kopialib/lib_repo_ex_test.go 覆盖了WriteAt、并发写、异步写、大稀疏写等多种场景。Kopia 仓库增量感知对象扩展Kopia 仓库的 CAOS 实现了 Unified Repo 的 Objects但它只支持全量与顺序写。为支持可跳过写设计在既有 CAOS 之上创建了Incremental Aware Object Extension增量感知对象扩展块地址表BATKopia CAOS 使用块地址表Block Address TableBAT跟踪对象全量与增量备份都复用它。在增量感知对象扩展中一个对象代表一个卷全量备份跳过的区域由扩展写成全 ZERO——因为 Kopia 仓库接口不支持可跳过写。这没问题ZERO 数据会被 Kopia 仓库去重实际不会写入备份存储增量备份跳过的区域从父对象克隆表项写过的区域写入 Kopia 仓库并生成新表项。最终扩展为增量对象生成覆盖其全部逻辑空间的新块地址表。增量感知对象扩展在ObjectWriteOptions的AccessMode为块模式数据访问时自动激活。去重与 1MB 块大小增量感知对象扩展使用固定大小分割器做去重对块级备份足够原因有三磁盘写不同于文件不会向磁盘中间插入数据只做原地更新或追加数据不会在两个磁盘或同一磁盘的两次备份之间漂移文件系统对磁盘的 IO 一般按特定大小对齐如 NTFS 与 ext4 的 4KB只要块大小是该大小的倍数就能有效避免一次 IO 破坏两个去重块当磁盘作为无文件系统的裸块设备使用时IO 同样按特定边界对齐。块大小特意选择1MB理由1MB 是文件系统 4KB 或裸块设备常见块大小的倍数1MB 是现代操作系统MBR 与 GPT的分区起始边界分区元数据可被隔离到独立块中块越多仓库索引越多1MB 对 Kopia 仓库的索引开销是适中的取值。复用 BAT 带来的收益与性能由于复用并保持既有 CAOS 块地址表不变带来以下收益所有表项仍由 Kopia CAOS 管理Velero 无需额外维护数据Velero 块上传器写出的对象对 Kopia 依然可识别全量与增量皆可Kopia 仓库既有的数据管理快照 GC、仓库维护等对块上传器生成的对象依然有效。更重要的是性能增量写时不从父对象复制任何数据只克隆对象块地址表项备份删除时也不需要移动任何数据只删除对象的 BAT。上传器行为约束块上传器的可跳过写必须对齐 1MB 边界因为增量感知对象扩展需要从父对象克隆被跳过的表项。文件系统上传器仍使用变长去重两种上传器的数据可以共存于同一个 Kopia 仓库虽然通常不会互相去重。此外卷可以被扩容且卷大小不一定对齐 1MB 边界由于增量感知对象扩展不能部分复制 BAT 表项上传器需要妥善处理卷大小变化。CBT 层CBT 层提供两类功能全量备份提供已分配的数据区间。例如 1TB 卷中只有 1MB 文件时上传器可跳过无真实数据的区间增量备份基于提供的父快照提供变化的数据区间上传器跳过未变化数据从而实现增量备份。对情况 1上传器以已分配数据的偏移调用 Unified Repo Object 的WriteAt偏移之前的区间由统一仓库填 ZERO对情况 2上传器以变化数据的偏移调用WriteAt偏移之前的区间由统一仓库从父对象克隆。每次备份都会保存一个 changeId下一次备份取出父快照的 changeId 并用它检索 CBT。从 Kubernetes API 拿到的 CBT 是一组BlockMetadata每个区间可以是固定大小或可变大小块上传器需要维护对自身备份仓库与上传器友好的粒度。从 API 侧GetMetadataAllocated或GetMetadataDelta会被循环调用直到取回全部BlockMetadata同时考虑到上传器内部读写多流的复杂度工作流应由上传器驱动而非 CBT 迭代器驱动因此实践中应在传给上传器之前把全部已分配/变化块取回并保存。由于直接保存BlockMetadata列表非常耗内存设计采用Bitmap数据结构保存已分配/变化块称为 CBT Bitmap。CBT Bitmap 的块大小可设为 1MB 或其倍数但更大的块会放大备份体积因此采用1MB。CSI Snapshot Metadata Service、CBT 层与上传器之间的交互如下这样 CBT 层与上传器解耦CBT Bitmap 充当上传器的北向参数。块上传器块上传器由异步运行的 reader 与 writer 组成备份时reader 从块设备读数据并参考 CBT Bitmap 判断已分配/变化块writer 把数据写入 Unified Repo恢复时reader 从 Unified Repo 读数据writer 把数据写入块设备。reader 与 writer 通过环形缓冲区连接reader 把块数据推入环形缓冲区writer 取出数据写入目标。为提升性能块设备以direct IO打开避免数据无谓地经过系统缓存。恢复时为优化写吞吐与存储用量零块应被跳过恢复到新卷或取消映射恢复到已有卷。为统一覆盖两种情况使用 SCSI 命令WRITE_SAME逻辑如下检测从备份读到的块是否全为零数据若为全零上传器通过BLKZEROOUTioctl 发送WRITE_SAMESCSI 命令若调用失败回退到保守方式把全零字节直接写入磁盘。上传器实现与操作系统相关但由于 Windows 容器不支持块卷当前实现仅面向 Linux。这与 Volume Snapshot Data Movement 设计 中Kopia 块模式上传器仅支持非 Windows 平台的说明一致。ChangeId 与快照保留ChangeId 的一致性保障ChangeId 标识 CBT 生成所基于的基准它必须严格映射到仓库中的父快照否则增量备份将产生数据损坏。因此ChangeId 与仓库快照一起保存数据移动器总是从 Unified Repo 一起查询父快照与 ChangeId避免不匹配上传器内部上层DataUpload 控制器也可提供 ChangeId 作为双重确认机制收到的 ChangeId 会与所提供快照中的 ChangeId 重新核对。在 Kubernetes API 中changeId 由BaseSnapshotId表示。changeId 的检索是存储相关的通常从 VolumeSnapshotContent 对象的SnapshotHandle获取但某些存储也可能从其他位置获取也就是说SnapshotHandle与 changeId 可能是两个不同的值此时两者都需要保留。卷快照保留策略存储/CSI 驱动对 changeId 的支持方式取决于存储能力分两种情形某些存储要求在调用GetMetadataDelta时父快照映射到 changeId始终存在因此只要存在基于它的增量备份父快照就不能删除某些存储计算变化时不需要父快照本身因此父备份完成后父快照可立即删除。现有 exposer 与情形 1 完美契合备份完成时快照照常删除。对情形 2由于必须保留快照exposer 需要如下改动每次备份结束时把当前 VolumeSnapshot 的deletionPolicy保持为Retain这样备份结束时删除 VolumeSnapshot 对象快照仍保留在存储中以保留的 changeId 作为BaseSnapshotId调用GetMetadataDelta删除备份时用保留的 snapshotHandle 重建一对 VolumeSnapshot-VolumeSnapshotContentdeletionPolicy设为delete删除重建的 VolumeSnapshot从而从存储中删除卷快照。由于无法自动探测某个卷支持哪种方式设计向用户暴露了设置卷快照保留方式的接口可放在 Volume Policy 的Action.Parameters中。默认 Velero 块数据移动器采用方式 1卷快照不保留若用户指定RetainSnapshot参数则采用方式 2。例如用户可以针对存储类 xxx 或 CSI 驱动 yyy 指定通过 CSI 快照配合 Velero 块数据移动器备份并保留快照。增量大小备份结束时上传器还会返回增量大小incremental size与 Velero 文件系统上传器一致表示基于给定 CBT 上传器实际处理的唯一数据量。回退到全量备份以下情况增量备份无法继续数据移动器回退到全量备份GetMetadataAllocated或GetMetadataDelta返回错误ChangeId 缺失父快照缺失。回退发生时卷从块级做全量备份但由于备份仓库的数据去重未分配/未变化的数据大概率会被去重。恢复时卷也会全量恢复前述零块处理依然生效因此未分配数据的写 IO 大概率会被消除。回退用于处理异常场景绝大多数备份/恢复不会触发。不规则卷大小与卷大小变化增量备份期间块上传器 IO 必须对齐去重块大小1MB但用户的卷大小没有对齐的硬性要求。为支持不规则大小的卷采取以下措施仓库中的卷对象始终按 1MB 对齐若卷大小不规则卷对象尾部以零字节填充真实大小记录在仓库快照中恢复时按真实大小恢复数据填充必须始终是零字节。当卷被扩容时增量备份可以继续块上传器支持写入任意大小的磁盘无需逐案例处理。具体处理方式与 CBT 循环配合读取RoundDownTo1M(newSize)与newSize之间的尾部数据若没有尾部数据卷大小已按 1MB 对齐调用WriteAt(newSize, nil)否则调用WriteAt(RoundDownTo1M(newSize), taildata)taildata也填充到 1MB。也就是说若 CBT 覆盖卷尾部无论扩容还是缩容与 CBT 循环配合即可否则卷扩容时WriteAt保证从父对象克隆适当的对象表项并为扩展区域追加零数据——特别是父卷大小不规则时其零填充字节也会被复用因此父对象的填充字节必须是零卷缩容时写尾部数据可确保新卷对象填充零字节而不是继承父对象的非零数据。取消、并行与进度报告取消复用现有取消机制块上传器外部无变化上传器内部在 reader 与 writer 中嵌入取消检查点使取消发生后执行能在合理时间内退出。并行数据移动器之间的并行复用既有机制——负载并发load concurrency。数据移动器内部上传器 reader 与 writer 始终并行运行数量恒为 1卷的顺序读/写总是最优没有证据表明多个 reader/writer 更有益。进度报告数据移动器外部复用既有机制内部进度更新嵌入上传器 writer。进度结构保持原样块数据移动器仍支持TotalBytes与BytesDonetype Progress struct { TotalBytes int64 json:totalBytes,omitempty BytesDone int64 json:doneBytes,omitempty }备份结束时块数据移动器的进度同样提供GetIncrementalSize以与文件系统数据移动器相同的方式向用户报告增量大小。该结构在 pkg/uploader/types.go 中已有定义而SnapshotInfo中的IncrementalSize字段pkg/uploader/types.go正是用于承载该值。可选备份类型full 与 incremental由于数据完整性等原因例如每 1 周或 1 个月做一次全量以确保增量链间数据完整性周期性全量备份是必要的。因此手动备份与备份调度都应支持备份类型full/incremental备份类型也会写入volumeInfo.json以支持可观测性。备份 TTL 仍用于指定备份的保留时长。默认全量与增量备份都是 30 天保留虽然对全量备份而言并不十分合理待 Velero 支持更精细的保留策略后可增强。当前变通做法为同一范围的备份创建两个调度——一个用于全量备份频率更低、TTL 更长一个用于增量备份正常频率、TTL 更短。文件系统数据移动器的对齐目前 Velero 文件系统数据移动器不支持可选备份类型一旦可能就总是做增量备份从用户体验看并不合理。因此为与块数据移动器对齐文件系统数据移动器也将支持备份类型。其数据路径已具备该能力只需向用户开放。备份描述备份描述中应体现备份类型有两处Backup CR 中的backupType用户选择的备份类型volumeInfo.json中记录的备份类型实际执行的类型。借助这两个值用户能知道实际备份类型以及是否发生了回退。已有备份描述中的DataMover项也应更新以反映实际完成备份的数据移动器可从volumeInfo.json获取。同步、删除、重启与日志Backup Sync同步不需要额外数据保持不变Backup Deletion删除 Velero 块数据移动器的仓库快照时不移动任何数据因此对仓库快照而言删除逻辑不变对卷快照保留场景删除逻辑会相应修改以删除被保留的快照Restarts复用既有机制无改动Logging日志机制不变。CRD 变更Backup CRD新增backupType字段backupType支持两个值full指示数据移动器做全量备份与incremental默认值做增量备份。spec: description: BackupSpec defines the specification for a Velero backup. properties: backupType: description: BackupType indicates the type of the backup enum: - full - incremental type: string该字段已落地到 API 类型见 pkg/apis/velero/v1/backup_types.goBackupType BackupType与同文件中的BackupTypeFull Full、BackupTypeIncremental Incremental常量pkg/apis/velero/v1/backup_types.go。DataUpload CRD新增parentSnapshot字段parentSnapshot支持以下取值回退到autoauto数据移动器从 Unified Repository 找到同一卷最近的快照作为父快照none数据移动器不分配父快照执行全量备份具体 snapshotID数据移动器用该 ID 查找父快照找不到则回退到全量备份。最后一个选项是为备份计划准备的当前不会使用可能在 Velero 支持精细保留策略时有用——目前 Velero 总是以最近备份作为父快照。当 Backup 的backupType为full时数据移动器控制器把 DataUpload 的parentSnapshot设为none为incremental时设为auto仅为向后兼容保留。spec: description: DataUploadSpec is the specification for a DataUpload. properties: parentSnapshot: description: |- ParentSnapshot specifies the parent snapshot that current backup is based on. If its value is or auto, the data mover finds the recent backup of the same volume as parent. If its value is none, the data mover will do a full backup If its value is a specific snapshotID, the data mover finds the specific snapshot as parent. type: string对应的 API 字段可见 pkg/apis/velero/v1/pod_volume_backup_types.go 中的ParentSnapshot当前位于 PodVolumeBackupSpec 中。DataDownload CRD不需要修改。插件数据移动器本设计不会破坏任何插件数据移动器。VolumePolicy 的增强同样可用于插件数据移动器用户可以通过 VolumePolicy 选择插件数据移动器方式与选择 Velero 内置数据移动器相同。DataUpload/DataDownload 控制器的现有实现逻辑可参考 pkg/controller/data_upload_controller.go 与 pkg/controller/data_download_controller.go其中处理DataMover类型与BackupType的细节可结合 pkg/util/datamover/datamover.go 阅读。安装、升级与 CLI安装无需变更。升级无影响。CRD 新增字段均为可选字段且具有向后兼容的取值。CLI备份类型参数加入 Velero CLIvelero backup create --full velero schedule create --full未指定该参数时默认执行增量备份。小结Velero Block Data Mover 设计在既有 VBDM 与 VGDP 之上以复用为主、增量改造的方式为 CSI 快照数据移动引入块级备份/恢复能力。核心思路可以概括为四条主线一是通过 Kubernetes CBT APIGetMetadataAllocated/GetMetadataDelta获取已分配/变化块并用 1MB 粒度的 CBT Bitmap 承载实现全量与增量备份二是通过 Unified Repo 接口的WriteAt、ParentObject、快照与元数据方法扩展以及 Kopia 仓库的 Incremental Aware Object Extension实现基于 BAT 克隆的增量写与零数据移动的删除三是通过块上传器的 reader/writer 环形缓冲、direct IO 与WRITE_SAME零块处理保证吞吐与写 IO 效率四是通过velero-block/velero-fs数据移动器类型、Volume Policy 的dataMover参数、backupType/parentSnapshotCRD 字段与--fullCLI 参数把选择权交给用户并保持向后兼容。需要说明的是当前设计明确聚焦 Kopia 仓库且实现仅面向 Linux 节点文件存储卷、Windows 节点与 PodVolume Backup 仍走文件系统级路径。随着 Kubernetes CBT API 在更多平台落地这套架构为 Velero 在降低 TCO、提升备份恢复吞吐方面提供了清晰的演进路径。【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考