企业官网建设流程全解析

Velero CSI Snapshot Data Movement 完整实战指南：原理、安装、备份恢复与深度调优

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

CSI Snapshot Data Movement（CSI 快照数据移动）是 Velero 中用于把 CSI 卷快照的数据"搬移"到预定义备份存储（BackupStorageLocation）的关键能力，它在完成 CSI 快照之后并不止步，而是借助数据移动器（Data Mover）把快照数据完整写入低成本、大容量的对象存储，从而解决本地存储不支持持久快照、以及跨云厂商迁移数据两大难题。读完本文，你将掌握该功能的适用场景与架构原理、Velero Node Agent 与备份存储的完整安装配置、基于--snapshot-move-data的备份/恢复操作流程，以及并行度、超时、资源配额、只读根文件系统等生产级调优与故障排查方法。

什么是 CSI Snapshot Data Movement

CSI Snapshot Data Movement 依据 Volume Snapshot Data Movement 设计文档 实现，专用于将 CSI 快照数据移动到备份存储位置。它通过 CSI 插件以与 CSI 快照备份 几乎相同的方式创建 CSI 快照，但区别在于：创建快照后并不停止，而是尝试通过各种数据移动器（data mover）访问快照数据，并将其备份到数据移动器所连接的备份存储中。最终，卷数据以一致的方式（consistent manner）备份到预定义的备份存储，备份完成后 Velero 会删除 CSI 快照，从而在存储侧释放快照所占空间。

典型适用场景

• 本地（on-premises）用户：本地存储通常不支持持久快照，若按照 CSI 快照备份 的方式长期保存卷快照，往往不可行、效率低下或成本高昂。该功能可将快照数据移动到成本更低、规模更大的存储上做长期保存。
• 公有云用户：该功能有助于实现多云（multiple cloud）策略——从一个云厂商备份卷快照，再保存或恢复到另一个云厂商，从而基于 Velero 的备份恢复能力自由地在不同云厂商间流转业务数据。

与 File System Backup 的关系

Velero 的 File System Backup（文件系统备份） 同样可以把卷数据备份到预定义存储。两者协同满足上述场景的不同需求，且只要可用就应优先使用 CSI Snapshot Data Movement，原因在于 File System Backup 是从存活的 PV（live PV）读取数据，数据并非在同一时间点捕获，一致性较差。此外，CSI Snapshot Data Movement 还带来更多数据访问方式，例如在块级别（block level）全量或增量地访问数据。

反过来，在 CSI 快照不可用的场景（例如存储平台没有卷快照插件，或正在使用 EFS、NFS、emptyDir、local 等没有原生快照的卷类型），File System Backup 就是唯一选择。

内置数据移动器与自定义数据移动器

CSI Snapshot Data Movement 同时支持内置数据移动器和自定义数据移动器。关于 Velero 如何与自定义数据移动器协作，可查看 Volume Snapshot Data Movement 设计文档。Velero 提供的内置数据移动器使用 Velero 内置的上传器（目前可用的是 Kopia 上传器）读取快照数据并写入统一仓库（Unified Repository，默认由 Kopia 仓库实现）。

由于 Velero 内置数据移动器既要恢复卷数据也要恢复元数据，因此数据移动器 Pod 必须以 root 用户运行。

Priority Class 配置

对于 Velero 内置数据移动器，CSI 快照数据移动期间启动的数据移动器 Pod 将使用 node-agent ConfigMap 中配置的优先级类名。node-agent DaemonSet 本身则在 Velero 安装时通过--node-agent-priority-class-name参数获得其优先级类。这有助于在资源受限的环境中保证正确的调度行为。

从源码看，node-agent 启动时会对配置的优先级类做校验（nodeagent/server.go）：若集群中存在该 PriorityClass 则使用之，否则记录警告并回退到默认优先级。node-agent ConfigMap 中的priorityClassName配置对 PodVolumeBackup、PodVolumeRestore、DataUpload、DataDownload 四类 Pod 均生效，详见 node-agent ConfigMap 文档。

部署准备

前提条件

1. 源集群 Kubernetes 版本1.20 及以上；
2. 源集群运行支持v1 API 级别卷快照的 CSI 驱动（Volume Snapshot 在 Kubernetes 1.20 中 GA）；
3. CSI Snapshot Data Movement 需要 Kubernetes 的MountPropagation 特性。

安装 Velero Node Agent

Velero Node Agent 是一个 Kubernetes DaemonSet，承载 Velero 数据移动控制器并负责启动数据移动器 Pod。如果使用 Velero 内置数据移动器，则必须安装 Node Agent，安装方式是在velero install时指定--use-node-agent标志。

Velero 内置数据移动器并不需要把 Pod 卷的 host path 挂载进 Node Agent Pod；默认安装会创建该 host path 以支持 fs-backup。如果不用 fs-backup 并希望从 Node Agent 中移除它，可以指定--node-agent-disable-host-path标志：

velero install --use-node-agent --node-agent-disable-host-path

对应的安装参数定义位于 install.go：--use-node-agent创建 Velero node-agent DaemonSet，--node-agent-disable-host-path表示不把 Pod 卷 host path 挂载到 node-agent（fs-backup 需要该挂载，其他备份方式可关闭）。

配置备份存储位置（BackupStorageLocation）

目前 Velero 备份仓库支持对象存储作为备份存储。Velero 从 BackupStorageLocation 获取参数来拼接访问备份存储的 URL。Velero 已知的对象存储提供商列在 supported providers（受支持的提供商） 中，对这些提供商 Velero 预定义了端点。若要使用其他备份存储，请确保其兼容 S3，并在 BackupStorageLocation 中提供正确的 bucket 名称与端点。Velero 会负责在备份存储中创建备份仓库前缀，因此请确保在 BackupStorageLocation 中正确指定。

Velero 每个命名空间创建一个备份仓库。例如，使用 Kopia 仓库在 AWS S3 上备份 namespace1 和 namespace2 两个命名空间，则 namespace1 的完整备份仓库路径为https://s3-us-west-2.amazonaws.com/bucket/kopia/ns1，namespace2 为https://s3-us-west-2.amazonaws.com/bucket/kopia/ns2。

根据所使用的云提供商插件，可能还有额外的安装步骤，请参考插件相关文档获取最新信息。

注意：目前 Velero 会在 velero 安装命名空间中创建一个名为velero-repo-credentials的 Secret，内含默认备份仓库密码。你可以在首次备份（包括 File System Backup、快照数据移动）指向该备份仓库之前，用自己经过 base64 编码的密码更新该 Secret，需更新的 key 为：

data: repository-password: <custom-password>

备份仓库是在安装带 node-agent 的 Velero 后、首次针对其执行备份时创建的。如果在首次备份（创建了备份仓库）之后才更新 Secret 密码，Velero 将无法连接旧备份。

在源集群启用 CSI 支持

在源集群上，Velero 需要通过 CSI 卷快照 API 操作 CSI 快照，因此必须启用EnableCSI特性开关。

自 release-1.14 起，原本独立的velero-plugin-for-csi仓库（即 Velero CSI 插件）已合并进velero主仓库，合并原因包括：VolumeSnapshot 数据移动器依赖 CSI 插件，整合更合理；降低 Velero 部署复杂度；便于未来做性能调优。因此不再需要单独安装 Velero CSI 插件：

velero install \ --features=EnableCSI \ --plugins=<object storage plugin> \ ...

目标集群的存储类配置

对于 Velero 内置数据移动，目标集群不一定需要 CSI 设施。但内置数据移动会创建一个与源集群中规格相同的 PVC，并期望卷以类似方式被供给，例如目标集群中应存在可用的同名存储类。

默认情况下，Velero 不会从备份中恢复存储类资源（它们是集群级资源）。但若指定了--include-cluster-resources恢复标志，则会恢复它们。对于跨提供商场景，源集群的存储类很可能在目标集群不可用。

在上述任一情况下，最佳实践是在目标集群中创建一个与源集群同名的可用存储类。这样即使指定了--include-cluster-resources，Velero 恢复时发现已存在同名存储类也会跳过恢复。如果目标集群中的存储类名称不同，可以按更改 PV/PVC 存储类的方法在恢复时修改 PVC 的存储类名称，也可以配置跳过从备份中恢复存储类资源。

自定义数据移动器

如果使用自定义数据移动器，请遵循该数据移动器说明中的任何额外前提条件。上述 Velero 侧配置中，node-agent 的安装与配置可能不是必需的（由数据移动器自身实现决定）。

执行备份

Velero 使用新的自定义资源DataUpload驱动数据移动。所选数据移动器会 watch 并协调（reconcile）这些 CR。Velero 允许用户按备份决定是否移动 CSI 快照数据，也允许按备份选择由哪个数据移动器来移动 CSI 快照数据，两者都只需在运行备份时传入一个参数。

使用 Velero 内置数据移动器备份：

velero backup create NAME --snapshot-move-data OPTIONS...

或使用自定义数据移动器：

velero backup create NAME --snapshot-move-data --data-mover DATA-MOVER-NAME OPTIONS...

这两个参数在 backup create 命令 中定义：--snapshot-move-data指定是否移动快照数据；--data-mover指定备份使用的数据移动器，未设置或设置为velero时使用内置数据移动器。

备份开始时，你会看到VolumeSnapshot与VolumeSnapshotContent对象被创建，但备份结束后这些对象会消失。创建快照后，会看到一个或多个DataUploadCR被创建。你可能还会看到 Velero 命名空间或集群范围内出现一些中间对象（如 Pod、PVC、PV），它们是用来帮助数据移动器移动数据的，备份完成后会被清理。

DataUploadCR 的 phase 在备份过程中会变化多次，最终进入Completed、Failed或Cancelled之一。从 CRD 定义（data_upload_types.go）可以看到完整的生命周期阶段枚举：New、Accepted、Prepared、InProgress、Canceling、Canceled、Completed、Failed。通过 watchDataUploadCR 即可看到阶段变化与上传进度：处理过程中，BYTES DONE表示已处理的卷数据量，TOTAL BYTES表示估算的卷数据总量，完成后两者相等；此外，DataUpload完成后INCREMENTAL BYTES会填入自该卷上次备份以来新增或变化的数据量。需要注意的是，由于 Kopia 的去重、压缩等机制，实际上传内容可能小于INCREMENTAL BYTES。

kubectl -n velero get datauploads -l velero.io/backup-name=YOUR_BACKUP_NAME -w

默认情况下INCREMENTAL BYTES不出现在kubectl get输出中，需要加-o wide参数查看该扩展字段：

kubectl -n velero get datauploads -o wide -l velero.io/backup-name=YOUR_BACKUP_NAME -w

从 CRD 的 printcolumn 标记（data_upload_types.go）可见，Bytes Done、Total Bytes直接来自.status.progress，而Incremental Bytes是 priority=10 的列（默认隐藏、-o wide时显示），另有Node列显示处理该 DataUpload 的节点。

备份完成后查看备份信息：

velero backup describe YOUR_BACKUP_NAME

kubectl -n velero get datauploads -l velero.io/backup-name=YOUR_BACKUP_NAME -o yaml

执行恢复

创建数据移动恢复时无需设置任何额外信息——配置会自动从备份中获取，即是否需要数据移动、由哪个数据移动器执行。

从 Velero 备份恢复：

velero restore create --from-backup BACKUP_NAME OPTIONS...

恢复开始时，你会看到一个或多个DataDownloadCR被创建。同样可能看到帮助数据移动的中间对象（Pod、PVC、PV），恢复完成后被清理。DataDownloadCR 的 phase 同样经历多次变化后进入Completed、Failed或Cancelled（阶段定义见 data_download_types.go）。watch DataDownload CR 查看阶段变化与下载进度：

kubectl -n velero get datadownloads -l velero.io/restore-name=YOUR_RESTORE_NAME -w

恢复完成后查看恢复信息：

velero restore describe YOUR_RESTORE_NAME

kubectl -n velero get datadownloads -l velero.io/restore-name=YOUR_RESTORE_NAME -o yaml

限制（Limitations）

• 块模式平台限制：CSI 与 CSI 快照同时支持文件系统卷模式和块卷模式。目前块模式仅支持非 Windows 平台，因为块模式代码调用了 Windows 平台不存在的某些系统调用。
• [Velero 内置数据移动器] 静态加密密钥：目前 Velero 对所有其创建的备份仓库使用一个静态、通用的加密密钥。这意味着任何能访问你备份存储的人都可能解密你的备份数据，务必适当限制对备份存储的访问。
• [Velero 内置数据移动器] 大文件去重扫描：尽管备份数据可以增量保存，但对于单个文件，内置数据移动器依赖去重来找出差异。这意味着大文件（例如存储数据库的文件）即使实际差异很小，也需要很长时间扫描以进行数据去重。
• [Velero 内置数据移动器] mount-constant identity 文件系统：在底层文件系统强制执行挂载恒定身份（mount-constant identity）的卷上（如 Azure Files SMB/CIFS、通过 blobfuse 挂载的 Azure Blob、GCP Cloud Storage FUSE 等），数据下载的chown/chmod可能"报告成功却什么都没改"，从而静默丢失文件属主（FUSE 挂载下还有权限位），且任何地方都不会出现错误。详细说明与补救方案参见 File System Backup 文档中的 File Ownership and Permission Preservation 章节——例如对 Azure Files SMB，可在 StorageClass 的mountOptions中添加idsfromsid,modefromsid并避免同时强制uid=/gid=/mode=，使真实属主与权限保存在共享的 NTFS 安全描述符中，从而跨备份/恢复保持完整保真。

故障排查

依次执行以下检查：

Velero server 与 daemonset Pod 是否在运行？

kubectl get pods -n velero

备份仓库是否存在且就绪？

velero repo get velero repo get REPO_NAME -o yaml

Velero 备份/恢复中是否有错误？

velero backup describe BACKUP_NAME velero backup logs BACKUP_NAME velero restore describe RESTORE_NAME velero restore logs RESTORE_NAME

DataUpload与DataDownload的状态如何？

kubectl -n velero get datauploads -l velero.io/backup-name=BACKUP_NAME -o yaml kubectl -n velero get datadownloads -l velero.io/restore-name=RESTORE_NAME -o yaml

Velero server 或 daemonset Pod 日志中是否有有用信息？

kubectl -n velero logs deploy/velero kubectl -n velero logs DAEMON_POD_NAME

注意：可通过在 deployment/daemonset Pod 模板的容器命令参数中加入--log-level=debug来提高 Pod 日志的详细程度。

如果使用自定义数据移动器，请遵循该数据移动器的说明获取额外的排查方法。

备份与恢复的工作原理

CSI 快照数据移动是 CSI 快照与数据移动的组合，由 Velero server、CSI 插件和数据移动器共同执行。本节列出工作的一般概念，详细机制与工作流可参考 Volume Snapshot Data Movement 设计文档 及 VGDP Micro Service For Volume Snapshot Data Movement 设计。

自定义资源与控制器

Velero 定义了三个相关 CRD 及对应控制器：

• DataUpload——表示某个卷快照的数据上传。CSI 插件为每个 CSI 快照创建一个DataUpload，数据移动器需处理这些 CR 以完成数据上传。Velero 内置数据移动器在每个节点（node-agent DaemonSet 中）运行该资源的控制器；不同节点的控制器可能处理同一 CR 的不同阶段，但最终数据传输由某一个节点上的数据移动器 Pod 完成。
• DataDownload——表示某个卷快照的数据下载。CSI 插件为每个待恢复卷创建一个DataDownload。与 DataUpload 相同，Velero 内置数据移动器在每个节点上运行其控制器，最终由一个节点上的数据移动器 Pod 完成数据传输。
• BackupRepository——表示/管理 Velero 备份仓库的生命周期。当某个命名空间的首次 CSI 快照备份/恢复被请求时，Velero 会为该命名空间创建一个备份仓库，可通过velero repo get查看。该 CR 供 Velero 内置数据移动器使用，自定义数据移动器可用可不用。

自定义数据移动器涉及的其他资源或控制器，请参见该数据移动器的说明。

备份流程

Velero 备份 CSI 快照数据移动的普通资源方式与其他备份类型相同。当遇到 PVC 时，会执行特定逻辑：

• 发现 PVC 对象时，Velero 通过 Backup Item Action 调用 CSI 插件；
• CSI 插件首先通过创建VolumeSnapshot和VolumeSnapshotContent对 PVC 创建 CSI 快照；
• CSI 插件检查是否需要数据移动，若需要则创建一个DataUploadCR，然后返回 Velero 备份流程；
• Velero 此时可继续备份其他资源，包括其他 PVC 对象；
• Velero 备份控制器周期性向 CSI 插件查询数据移动状态，周期可通过 Velero server 参数--item-operation-sync-frequency配置（默认 10s，定义见 config.go）。查询时 CSI 插件转而检查DataUploadCR 的 phase；
• 当所有DataUploadCR 进入终态（Completed、Failed或Cancelled）时，Velero 持久化所有必要信息并完成备份。

其余要点：

• CSI 插件期望有数据移动器处理DataUploadCR；若备份未配置数据移动器，则由 Velero 内置数据移动器处理。
• 若DataUploadCR 未在给定时间内到达终态，该 CR 将被取消。可按备份通过--item-operation-timeout设置超时值，默认4 小时（server 端默认值定义见 config.go）。
• Velero 内置数据移动器从 CSI 快照创建卷，并按用户定义的备份存储位置把数据传输到备份存储。
• 从 CSI 快照创建卷后，内置数据移动器等待 Kubernetes 供给该卷（不同存储提供商耗时不同）；若供给未在给定时间内完成，则取消该DataUploadCR。该超时可通过 node-agent 参数data-mover-prepare-timeout配置，默认30 分钟（定义见 nodeagent/server.go）。
• 内置数据移动器启动一个数据移动器 Pod，将数据从已供给的卷传输到备份存储。
• 数据传输完成或发生任何错误时，内置数据移动器将DataUploadCR 置为终态Completed或Failed。
• 内置数据移动器还监控对DataUploadCR 的取消请求，一旦发生，便取消进行中的活动、清理中间资源并将DataUpload置为Cancelled。
• 整个数据传输期间，内置数据移动器监控数据移动器 Pod 的状态，并在DataUpload置为终态后删除该 Pod。

恢复流程

Velero 恢复 CSI 快照数据移动的普通资源方式与其他恢复类型相同。遇到 PVC 时：

• 发现 PVC 对象时，Velero 通过 Restore Item Action 调用 CSI 插件；
• CSI 插件检查备份信息，若涉及数据移动则创建一个DataDownloadCR，然后返回 Velero 恢复流程；
• Velero 继续恢复其他资源，包括其他 PVC 对象；
• Velero 恢复控制器周期（同样由--item-operation-sync-frequency控制，默认 10s）向 CSI 插件查询数据移动状态，CSI 插件转而检查DataDownloadCR 的 phase；
• 当所有DataDownloadCR 进入终态时，恢复完成。

其余要点：

• CSI 插件期望与备份相同的（即备份中配置的）数据移动器处理DataDownloadCR；若备份未配置数据移动器，则由内置数据移动器处理。
• 若DataDownload未在给定时间内到达终态，该 CR 被取消，超时同样由--item-operation-timeout参数设置。
• 内置数据移动器创建与源卷规格相同的卷。
• 等待供给，超时由同一 node-agent 参数data-mover-prepare-timeout控制（默认 30 分钟）。
• 卷供给完成后，启动数据移动器 Pod 从备份存储（按用户定义的备份存储位置）传输数据。
• 传输完成或出错时置DataDownload为Completed/Failed；监控取消请求并支持Cancelled终态与中间资源清理；传输结束后删除数据移动器 Pod。

备份删除与仓库维护

备份创建时，卷数据的快照被保存进仓库，该快照是对仓库中卷数据的引用。删除备份时，Velero 调用仓库删除仓库快照，仓库快照在备份删除后立即消失，此时仓库中被备份的卷数据变成孤儿数据，但不会立即被删除，而是依赖仓库的维护功能删除孤儿数据。

因此，删除备份后，在若干次完整维护任务成功完成之前，备份存储容量不会减少；出于同样原因，应检查并确保周期性的仓库维护任务正常运行并成功完成。即使删除所有备份及其备份数据（通过仓库维护），备份存储仍非空的——其中保留了一些仓库元数据以维持备份仓库实例存在。Velero 从不删除这些仓库元数据；若确定不会再使用该备份仓库，可以手动清空备份存储。

对于 Velero 内置数据移动器，Kopia 上传器可能保留一些不由 Velero 管理的内部快照。正常情况下这些内部快照会随备份运行被删除；但若某个备份中途中止（从而产生了一些内部快照）且之后不再运行新备份，可能会有内部快照残留。这种情况下，既然已停止使用该备份仓库，可以手动从备份存储中删除整个仓库元数据。

并行度（Parallelism）

Velero 会并发调用 CSI 插件处理卷，因此DataUpload/DataDownloadCR 由 CSI 插件并发创建。CR 以何种方式被处理，完全取决于备份/恢复所选的数据移动器。

对于 Velero 内置数据移动器，它利用 Kubernetes 调度器把与某个DataUpload/DataDownloadCR 关联的快照卷/恢复卷挂载到特定节点，然后该节点（node-agent DaemonSet 中）的DataUpload/DataDownload控制器处理该 CR。默认情况下，一个节点上的控制器一次处理一个请求，可通过 node-agent Concurrency 配置 增加每个节点的并发数。也就是说：快照卷/恢复卷可能分布在不同节点，其关联 CR 可被并行处理；而同一节点上的快照卷/恢复卷，其关联 CR 默认串行处理，可按 node-agent Concurrency 配置 改为并发。

准备阶段挂载快照卷/恢复卷可能产生多个中间对象，可通过配置 node-agent Prepare Queue Length 控制中间对象的数量。

可通过 watchDataUpload/DataDownloadCR 查看它们被哪个节点处理及并行情况：

kubectl -n velero get datauploads -l velero.io/backup-name=YOUR_BACKUP_NAME -w

kubectl -n velero get datadownloads -l velero.io/restore-name=YOUR_RESTORE_NAME -w

单个卷内部的并行度如下：

• 文件系统模式卷：卷内文件并行处理。可用--parallel-files-upload备份标志或--parallel-files-download恢复标志控制并行处理的文件数；若未设置，Velero 默认按运行备份/恢复的节点 CPU 核心数决定并行度。也就是说，并行度不受数据移动器 Pod 上 CPU request/limit 的影响（Kopia 上传器读取该配置的实现见 uploader_config.go）。
• 块模式卷：无并行，块数据按顺序处理。

另外注意：Golang 1.25 及更高版本会尊重 Pod 的 CPU limit 来决定提供给进程的物理线程数（容器感知的 GOMAXPROCS），因此 Velero 1.18（使用 Golang 1.25）及以后版本，若给数据移动器 Pod 设置了 CPU limit，可能无法获得默认并行度下的预期性能（如备份/恢复吞吐），影响程度随卷数据而异。如有必要，可根据数据移动器 Pod 的 CPU limit 定制--parallel-files-upload或--parallel-files-download。

重启与恢复执行

Velero server 重启时，若资源备份/恢复已完成（即备份/恢复已越过InProgress状态、正在等待数据移动完成），Velero 会重新捕获进行中数据移动的状态并恢复执行。node-agent 重启时，Velero 尝试重新捕获进行中数据移动的状态并恢复执行；若恢复失败，数据移动会被取消。

取消机制

目前 Velero 备份/恢复不支持由用户发起端到端取消。但 Velero 会在以下场景自动取消DataUpload/DataDownload：

• Velero server 重启且备份/恢复处于InProgress状态；
• node-agent 重启且既有DataUpload/DataDownload恢复失败；
• 正在进行的备份/恢复被删除；
• 备份/恢复在条目操作超时前未完成（默认4 小时）。

支持取消的自定义数据移动器可取消其进行中的任务并清理中间资源。Velero 内置数据移动器支持取消。

支持 ReadOnlyRootFilesystem 设置

当 Velero server Pod 的 SecurityContext 将ReadOnlyRootFileSystem设为 true 时，Velero server Pod 的文件系统以只读模式运行，此时备份删除可能失败，因为仓库需要向 Pod 根文件系统写入一些缓存和配置数据：

Errors: /error to connect repo with storage: error to connect to repository: unable to write config file: unable to create config directory: mkdir /home/cnb/udmrepo: read-only file system

解决办法是把这些目录做成临时（ephemeral）Kubernetes 卷，使其不计入 Pod 根文件系统。user-name是 Velero Pod 的运行用户名，默认值为cnb：

apiVersion: apps/v1 kind: Deployment metadata: name: velero namespace: velero spec: template: spec: containers: - name: velero ...... volumeMounts: ...... - mountPath: /home/<user-name>/udmrepo name: udmrepo - mountPath: /home/<user-name>/.cache name: cache ...... volumes: ...... - emptyDir: {} name: udmrepo - emptyDir: {} name: cache ......

目前 Velero 不允许对数据移动器 Pod 设置ReadOnlyRootFileSystem，因此数据移动器 Pod 的根文件系统始终可写。

资源消耗

上传器和仓库在备份/恢复期间都会消耗可观的 CPU/内存，尤其是大量小文件或大备份规模场景。

对于 Velero 内置数据移动器，Velero 为数据移动器 Pod 使用BestEffort QoS（不设置 CPU/内存 request/limit），以确保备份/恢复在任何情况下都不会因资源节流而失败。若要限制 CPU/内存使用，需要定制数据移动器 Pod 资源限制。CPU/内存消耗始终与备份/恢复的数据规模相关，建议参考性能指导，并强烈建议自行测试以找到最适合自己数据的资源限制。

恢复期间，仓库还可能缓存数据/元数据以减少网络开销并加速恢复。仓库使用自己的策略存储和清理缓存。对于 Kopia 仓库，默认缓存存放在数据移动器 Pod 的根文件系统中。如果根文件系统空间有限，数据移动器 Pod 可能因临时存储耗尽而被驱逐，导致恢复失败。为此 Velero 提供两个应对手段：

• 为每个备份仓库配置缓存大小上限，详见备份仓库配置；
• 为缓存数据配置专用卷，详见数据移动缓存卷。

节点选择

数据移动备份/恢复运行在哪个节点由数据移动器决定。对于 Velero 内置数据移动器，它利用 Kubernetes 调度器把与DataUpload/DataDownload关联的快照卷/恢复卷挂载到特定节点，数据移动即在该节点发生。备份时，可通过数据移动备份节点选择干预该调度过程，从而按需决定哪些节点应/不应运行数据移动备份。恢复时不支持该干预，因为有时数据移动恢复必须运行在恢复的工作负载 Pod 被调度到的同一节点。

BackupPVC 与 RestorePVC 配置

BackupPVC是数据移动备份期间使用的中间持久卷声明（PVC），用于提供高效的数据访问。在复杂存储环境中，优化BackupPVC配置可显著提升备份性能，BackupPVC 配置文档 介绍了高级配置选项，用户可根据存储提供商的能力微调访问模式与存储类设置。

同理，RestorePVC是数据移动恢复期间使用的中间 PVC。有时需要配置RestorePVC以提升恢复性能，RestorePVC 配置文档 介绍了基于存储提供商能力微调访问模式与存储类的高级配置选项。

参考阅读

• Volume Snapshot Data Movement 设计文档：功能架构、备份/恢复时序、CRD 全量 spec、暴露（Expose）、取消、并行等细节
• CSI 快照备份：与数据移动配合使用的 CSI 快照能力
• File System Backup：同为卷数据备份手段，含文件属主与权限保留问题详解
• BackupStorageLocation API 类型：备份存储位置字段说明
• DataUpload/DataDownload CRD 定义：DataUpload 的 spec、status 与阶段枚举源码

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