企业官网建设流程全解析

Velero 备份删除命令完全指南：从ark delete backup到velero backup delete的原理与实战

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

本文是 Velero（前身 Ark）备份删除命令的权威技术参考与实战指南。它以 v0.8.0 时代的 CLI 参考文档ark delete backup为起点，结合当前仓库中velero backup delete的完整源码实现（pkg/cmd/cli/backup/delete.go），系统讲解删除命令的全部参数、确认机制、异步删除请求的底层工作流、批量删除的标签选择器用法，以及只读存储位置等边界场景的行为。读完本文，你将能安全、精确地在生产集群中删除单个或多个 Velero 备份，并理解删除操作"提交请求≠立即完成"的异步本质。

命令概览：删除一个备份

在 Ark 时代，删除备份的命令为：

ark delete backup NAME [flags]

在当前的 Velero 代码库中，该命令由 NewDeleteCommand 注册，调用形式升级为：

velero backup delete NAME [flags]

命令行摘要（Synopsis）始终只有一个语义：Delete a backup（删除一个备份）。命令本身不直接销毁备份，而是通过 Kubernetes API 在 Velero 命名空间中创建一个DeleteBackupRequest自定义资源，由服务端控制器异步完成真正的清理（详见下文"异步删除工作流"）。

命令选项（Options）

原参考文档中该命令只暴露了两个自有标志，其语义在当前源码中均得到保留与扩充：

--confirm标志在源码中由confirm.ConfirmOptions统一实现（pkg/cmd/util/confirm/confirm.go）。核心逻辑位于 Run：

if !o.Confirm && !confirm.GetConfirmation() { // Don't do anything unless we get confirmation return nil }

即：未传--confirm时，命令会从标准输入读取用户响应，循环提示Are you sure you want to continue (Y/N)?，只有输入y（大小写不敏感）才继续执行；输入n或直接中断则安全退出。这一设计防止误删，也解释了为什么在脚本或 CI 环境中必须显式携带--confirm。

继承自父命令的全局选项

除自有标志外，velero backup delete还继承父命令的全局选项。这些选项控制着客户端如何连接 Kubernetes API Server，以及日志的输出方式：

这些全局标志并非 Velero 独有，而是继承了 Kubernetes 生态常见的命令行惯例，便于在排查问题时获得更细粒度的日志输出。

删除的目标选择：名称、选择器与全量

当前实现支持三种互斥的删除目标指定方式，由 SelectOptions 统一校验：

1. 按名称指定：velero backup delete backup-1 backup-2，可一次删除多个具名备份；
2. 按标签选择器指定：velero backup delete --selector velero.io/schedule-name=schedule-1，删除所有匹配标签的备份；
3. 全量删除：velero backup delete --all，删除命名空间下的所有备份。

其校验逻辑要求"恰好指定一种"：

if !xor(hasNames, hasAll, hasSelector) { return errors.New("you must specify exactly one of: specific " + o.SingularTypeName + " name(s), the --all flag, or the --selector flag") }

因此同时传入名称与--all会直接报错，而非静默选择其一。

删除执行流程：源码级拆解

从 Run 的实现看，一次velero backup delete调用完整经历以下步骤：

第 1 步：确认（Confirmation）—— 若未指定--confirm，先交互确认，拒绝则立即返回。

第 2 步：收集待删除备份—— 按名称逐个Get对应Backup资源；按选择器或--all时，通过List拉取匹配的备份列表（--all即使用labels.Everything()全量标签选择器）。如果最终没有找到任何备份，输出No backups found并正常退出。

第 3 步：逐备份创建删除请求—— 对每个备份，校验其引用的BackupStorageLocation（BSL）：

• 备份未设置存储位置（b.Spec.StorageLocation为空）时拒绝删除；
• 目标 BSL 处于只读模式（AccessMode == BackupStorageLocationAccessModeReadOnly）时拒绝删除，防止在只读归档存储上误触发清理。

通过校验后，为每个备份构建一个DeleteBackupRequest对象，并打上velero.io/backup-name与velero.io/backup-uid标签、以备份名-为前缀生成随机名称，随后调用CreateRetryGenerateName创建（见 builder/delete_backup_request_builder.go）。

第 4 步：输出提示—— 每个请求创建成功后打印：

Request to delete backup "backup-1" submitted successfully. The backup will be fully deleted after all associated data (disk snapshots, backup files, restores) are removed.

这句输出正是理解删除模型的关键：CLI 只负责提交请求，实际删除由控制器异步完成。

异步删除工作流：DeleteBackupRequest 与控制器

删除请求为何异步？因为一次完整的备份删除需要清理的对象远超单个 CR：云盘快照、对象存储中的备份文件、相关的 PodVolumeBackup/PodVolumeRestore、以及依赖该备份的还原记录等。若由 CLI 同步执行，单次调用可能阻塞数分钟甚至更久。

因此 Velero 采用"请求 + 控制器"模式：

• CLI 提交DeleteBackupRequestCR（由 backupDeletionReconciler 监听）；
• 控制器以DeleteBackupRequest为主资源注册 watch（SetupWithManager），并具备对backups资源的delete权限（源码中的 kubebuilder RBAC 注解）；
• 控制器协调期间依次删除备份的关联数据与资源，请求完成后DeleteBackupRequest状态进入终态；
• 控制器还会每小时周期性扫描一次DeleteBackupRequest列表，确保过期请求能被回收（源码中deleteBackupRequestMaxAge = 24 * time.Hour即请求对象的最长保留期限）。

这意味着删除命令返回"提交成功"并不代表数据已消失，查询DeleteBackupRequest状态才是确认删除完成的正规手段。

实战示例

以下示例直接取自当前命令源码中的Example段（[pkg/cmd/cli/backup/delete.go#L46-L59），全部可直接执行：

# 删除名为 "backup-1" 的备份（会先弹出 Y/N 交互确认） velero backup delete backup-1 # 删除名为 "backup-1" 的备份，跳过交互确认（适合脚本/CI） velero backup delete backup-1 --confirm # 一次删除名为 "backup-1" 和 "backup-2" 的两个备份 velero backup delete backup-1 backup-2 # 删除由 schedule "schedule-1" 触发的所有备份（按标签选择器） velero backup delete --selector velero.io/schedule-name=schedule-1 # 删除命名空间下全部备份（谨慎使用） velero backup delete --all

配合全局选项的典型场景：

# 指定非默认命名空间与 kubeconfig 删除备份 velero backup delete backup-1 --confirm \ -n velero \ --kubeconfig /path/to/kubeconfig \ --kubecontext my-context

边界行为与测试验证

当前仓库用测试固化了若干关键边界行为（pkg/cmd/cli/backup/delete_test.go）：

• 命名空间隔离：测试TestDeleteCommand在velero命名空间创建backup-name-1、在default命名空间创建backup-name-2，随后执行删除，结果backup-name-2报backups.velero.io "backup-name-2" not found——证明删除仅作用于-n指定的命名空间。
• 只读 BSL 拦截：测试TestDeleteCommandReadOnlyBSL为备份关联一个AccessMode(ReadOnly)的存储位置后执行删除，断言错误信息为cannot delete backup "backup-readonly" because backup storage location "readonly-bsl" is currently in read-only mode，并确认没有生成任何DeleteBackupRequest。这与 Run 中的只读校验分支一一对应。

相关命令

• 删除属于资源级删除命令的一部分，其父命令velero delete的参考见 ark_delete.md（当前版本为velero delete，可删除备份、还原、调度、存储位置等资源）。
• 与删除配套的管理操作包括：velero backup create（创建备份）、velero backup get（查看备份）、velero backup describe（查看详情）。若只是清理本地文件而非备份，可使用velero backup delete配合后续的对象存储清理工具，而非手动删除对象存储中的文件。

小结

velero backup delete（前身ark delete backup）是一条语义简单但实现严谨的命令：--confirm守护交互安全，名称/选择器/--all三种目标方式满足从精确到批量的删除需求，而"提交DeleteBackupRequest→ 控制器异步清理"的架构则保证了大规模删除的可靠性。理解这些源码级细节，能帮助你在实际运维中准确预判命令行为、解读输出信息，并安全地将其编排进自动化流程。

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