Velero CSI Snapshot Data Movement 完整实战指南原理、安装、备份恢复与深度调优【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/veleroCSI Snapshot Data MovementCSI 快照数据移动是 Velero 中用于把 CSI 卷快照的数据搬移到预定义备份存储BackupStorageLocation的关键能力它在完成 CSI 快照之后并不止步而是借助数据移动器Data Mover把快照数据完整写入低成本、大容量的对象存储从而解决本地存储不支持持久快照、以及跨云厂商迁移数据两大难题。读完本文你将掌握该功能的适用场景与架构原理、Velero Node Agent 与备份存储的完整安装配置、基于--snapshot-move-data的备份/恢复操作流程以及并行度、超时、资源配额、只读根文件系统等生产级调优与故障排查方法。什么是 CSI Snapshot Data MovementCSI 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 是从存活的 PVlive 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 文档。部署准备前提条件源集群 Kubernetes 版本1.20 及以上源集群运行支持v1 API 级别卷快照的 CSI 驱动Volume Snapshot 在 Kubernetes 1.20 中 GACSI Snapshot Data Movement 需要 Kubernetes 的MountPropagation 特性。安装 Velero Node AgentVelero 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-agentfs-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/ns1namespace2 为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 \ --featuresEnableCSI \ --pluginsobject storage plugin \ ...目标集群的存储类配置对于 Velero 内置数据移动目标集群不一定需要 CSI 设施。但内置数据移动会创建一个与源集群中规格相同的 PVC并期望卷以类似方式被供给例如目标集群中应存在可用的同名存储类。默认情况下Velero 不会从备份中恢复存储类资源它们是集群级资源。但若指定了--include-cluster-resources恢复标志则会恢复它们。对于跨提供商场景源集群的存储类很可能在目标集群不可用。在上述任一情况下最佳实践是在目标集群中创建一个与源集群同名的可用存储类。这样即使指定了--include-cluster-resourcesVelero 恢复时发现已存在同名存储类也会跳过恢复。如果目标集群中的存储类名称不同可以按更改 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-nameYOUR_BACKUP_NAME -w默认情况下INCREMENTAL BYTES不出现在kubectl get输出中需要加-o wide参数查看该扩展字段kubectl -n velero get datauploads -o wide -l velero.io/backup-nameYOUR_BACKUP_NAME -w从 CRD 的 printcolumn 标记data_upload_types.go可见Bytes Done、Total Bytes直接来自.status.progress而Incremental Bytes是 priority10 的列默认隐藏、-o wide时显示另有Node列显示处理该 DataUpload 的节点。备份完成后查看备份信息velero backup describe YOUR_BACKUP_NAMEkubectl -n velero get datauploads -l velero.io/backup-nameYOUR_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-nameYOUR_RESTORE_NAME -w恢复完成后查看恢复信息velero restore describe YOUR_RESTORE_NAMEkubectl -n velero get datadownloads -l velero.io/restore-nameYOUR_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 yamlVelero 备份/恢复中是否有错误velero backup describe BACKUP_NAME velero backup logs BACKUP_NAME velero restore describe RESTORE_NAME velero restore logs RESTORE_NAMEDataUpload与DataDownload的状态如何kubectl -n velero get datauploads -l velero.io/backup-nameBACKUP_NAME -o yaml kubectl -n velero get datadownloads -l velero.io/restore-nameRESTORE_NAME -o yamlVelero server 或 daemonset Pod 日志中是否有有用信息kubectl -n velero logs deploy/velero kubectl -n velero logs DAEMON_POD_NAME注意可通过在 deployment/daemonset Pod 模板的容器命令参数中加入--log-leveldebug来提高 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 管理的内部快照。正常情况下这些内部快照会随备份运行被删除但若某个备份中途中止从而产生了一些内部快照且之后不再运行新备份可能会有内部快照残留。这种情况下既然已停止使用该备份仓库可以手动从备份存储中删除整个仓库元数据。并行度ParallelismVelero 会并发调用 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-nameYOUR_BACKUP_NAME -wkubectl -n velero get datadownloads -l velero.io/restore-nameYOUR_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/DataDownloadVelero 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解决办法是把这些目录做成临时ephemeralKubernetes 卷使其不计入 Pod 根文件系统。user-name是 Velero Pod 的运行用户名默认值为cnbapiVersion: 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Velero CSI Snapshot Data Movement 完整实战指南：原理、安装、备份恢复与深度调优
Velero CSI Snapshot Data Movement 完整实战指南原理、安装、备份恢复与深度调优【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/veleroCSI Snapshot Data MovementCSI 快照数据移动是 Velero 中用于把 CSI 卷快照的数据搬移到预定义备份存储BackupStorageLocation的关键能力它在完成 CSI 快照之后并不止步而是借助数据移动器Data Mover把快照数据完整写入低成本、大容量的对象存储从而解决本地存储不支持持久快照、以及跨云厂商迁移数据两大难题。读完本文你将掌握该功能的适用场景与架构原理、Velero Node Agent 与备份存储的完整安装配置、基于--snapshot-move-data的备份/恢复操作流程以及并行度、超时、资源配额、只读根文件系统等生产级调优与故障排查方法。什么是 CSI Snapshot Data MovementCSI 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 是从存活的 PVlive 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 文档。部署准备前提条件源集群 Kubernetes 版本1.20 及以上源集群运行支持v1 API 级别卷快照的 CSI 驱动Volume Snapshot 在 Kubernetes 1.20 中 GACSI Snapshot Data Movement 需要 Kubernetes 的MountPropagation 特性。安装 Velero Node AgentVelero 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-agentfs-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/ns1namespace2 为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 \ --featuresEnableCSI \ --pluginsobject storage plugin \ ...目标集群的存储类配置对于 Velero 内置数据移动目标集群不一定需要 CSI 设施。但内置数据移动会创建一个与源集群中规格相同的 PVC并期望卷以类似方式被供给例如目标集群中应存在可用的同名存储类。默认情况下Velero 不会从备份中恢复存储类资源它们是集群级资源。但若指定了--include-cluster-resources恢复标志则会恢复它们。对于跨提供商场景源集群的存储类很可能在目标集群不可用。在上述任一情况下最佳实践是在目标集群中创建一个与源集群同名的可用存储类。这样即使指定了--include-cluster-resourcesVelero 恢复时发现已存在同名存储类也会跳过恢复。如果目标集群中的存储类名称不同可以按更改 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-nameYOUR_BACKUP_NAME -w默认情况下INCREMENTAL BYTES不出现在kubectl get输出中需要加-o wide参数查看该扩展字段kubectl -n velero get datauploads -o wide -l velero.io/backup-nameYOUR_BACKUP_NAME -w从 CRD 的 printcolumn 标记data_upload_types.go可见Bytes Done、Total Bytes直接来自.status.progress而Incremental Bytes是 priority10 的列默认隐藏、-o wide时显示另有Node列显示处理该 DataUpload 的节点。备份完成后查看备份信息velero backup describe YOUR_BACKUP_NAMEkubectl -n velero get datauploads -l velero.io/backup-nameYOUR_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-nameYOUR_RESTORE_NAME -w恢复完成后查看恢复信息velero restore describe YOUR_RESTORE_NAMEkubectl -n velero get datadownloads -l velero.io/restore-nameYOUR_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 yamlVelero 备份/恢复中是否有错误velero backup describe BACKUP_NAME velero backup logs BACKUP_NAME velero restore describe RESTORE_NAME velero restore logs RESTORE_NAMEDataUpload与DataDownload的状态如何kubectl -n velero get datauploads -l velero.io/backup-nameBACKUP_NAME -o yaml kubectl -n velero get datadownloads -l velero.io/restore-nameRESTORE_NAME -o yamlVelero server 或 daemonset Pod 日志中是否有有用信息kubectl -n velero logs deploy/velero kubectl -n velero logs DAEMON_POD_NAME注意可通过在 deployment/daemonset Pod 模板的容器命令参数中加入--log-leveldebug来提高 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 管理的内部快照。正常情况下这些内部快照会随备份运行被删除但若某个备份中途中止从而产生了一些内部快照且之后不再运行新备份可能会有内部快照残留。这种情况下既然已停止使用该备份仓库可以手动从备份存储中删除整个仓库元数据。并行度ParallelismVelero 会并发调用 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-nameYOUR_BACKUP_NAME -wkubectl -n velero get datadownloads -l velero.io/restore-nameYOUR_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/DataDownloadVelero 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解决办法是把这些目录做成临时ephemeralKubernetes 卷使其不计入 Pod 根文件系统。user-name是 Velero Pod 的运行用户名默认值为cnbapiVersion: 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考