Kubernetes 集群的可靠性不只取决于高可用架构，还取决于出问题后能否快速恢复。etcd 备份能恢复控制平面，但业务应用的持久化数据、配置项、命名空间关系往往散落在多个资源中。Velero 的作用正是在应用层做备份与迁移：它可以把这些 Kubernetes 对象和持久卷数据打包备份到对象存储，并按计划周期执行。
接下来会从组件原理、安装配置、定时任务、恢复演练几个部分展开。如果你已经在生产环境运行 Kubernetes，建议先在测试集群完整走一遍，尤其是恢复步骤，因为备份从来不是目的，能恢复才是。
一、Velero 的备份原理与组件构成
Velero 的架构并不复杂。部署到集群后，它会在 velero 命名空间运行一个 Deployment，内部通过一系列 CRD 来管理备份和恢复任务。核心 CRD 包括 Backup、Restore、Schedule、BackupStorageLocation 和 VolumeSnapshotLocation。其中 BackupStorageLocation 声明备份数据存到哪里，通常是 S3 兼容对象存储；VolumeSnapshotLocation 声明 PV 快照由哪个 CSI 驱动或云厂商快照服务处理。
一次定时备份的流程大致是这样：Schedule 控制器根据 cron 表达式创建 Backup 对象，Backup 控制器收集指定命名空间内的资源清单，同时通过快照或文件级备份处理持久卷数据，最后把 tar 包和元数据写入对象存储。对象存储里的 layout 按 backup 名称、资源类型分目录，恢复时 Velero 再将这些文件还原成 Kubernetes 对象。
这里有一个容易混淆的点：快照备份和文件级备份不是一回事。云厂商 CSI 快照速度快、对大数据量友好，但只支持有快照能力的卷；Restic 或 Kopia 文件级备份则可以在 Pod 内挂载卷后把文件逐层上传，慢一些但兼容性更好。Velero 1.10 以后推荐使用 node-agent 替代 restic，底层仍可配置 Kopia。
二、安装 Velero 并接入对象存储
安装前需要准备一个 S3 兼容桶。测试环境常用 MinIO，生产环境可用 AWS S3、阿里云 OSS 或腾讯云 COS。以 AWS S3 为例，先创建 IAM 用户并获取 Access Key，然后在目标区域建桶，例如 velero-backup-prod。MinIO 本地部署更简单，但要注意存储目录的持久化，否则 MinIO Pod 重启后备份数据会丢失。
创建凭据文件 credentials-velero，内容格式如下：
[default] aws_access_key_id = YOUR_ACCESS_KEY aws_secret_access_key = YOUR_SECRET_KEY
接着执行 Velero CLI 安装命令。假设使用 AWS 插件，桶名 velero-backup-prod，区域 us-east-1：
velero install \ --provider aws \ --plugins velero/velero-plugin-for-aws:v1.9.0 \ --bucket velero-backup-prod \ --backup-location-config region=us-east-1 \ --snapshot-location-config region=us-east-1 \ --secret-file ./credentials-velero \ --use-node-agent \ --default-volumes-to-fs-backup
如果使用 MinIO，需要额外指定 s3Url 和 forcePathStyle，例如 --backup-location-config region=minio,s3ForcePathStyle=true,s3Url=http://minio.default:9000，并创建对应的 Secret。安装完成后执行 velero version 和 kubectl get pods -n velero 验证控制器是否正常运行。
安装命令中的 --use-node-agent 会部署一个 DaemonSet，用于处理文件级备份。即使你的云盘支持快照，也建议开启文件级备份，因为 ConfigMap、Secret 等普通资源不用快照，但有些场景下 PVC 可能没有快照能力，文件级备份是兜底方案。
三、创建定时备份 Schedule
Velero 的 Schedule 资源使用标准 cron 表达式控制备份频率。下面是一个每天凌晨 2 点执行、保留 72 小时、备份所有命名空间并同时做卷快照的示例：
apiVersion: velero.io/v1
kind: Schedule
metadata:
name: daily-backup
namespace: velero
spec:
schedule: "0 2 * * *"
template:
ttl: 72h
includedNamespaces:
- "*"
storageLocation: default
snapshotVolumes: true
labels:
backup-type: daily
这个 YAML 中的 ttl 表示备份对象在对象存储中的保留时间，超过后 Velero 会自动清理。snapshotVolumes 为 true 时，Velero 会尝试对 PVC 关联的 PV 创建快照。如果你之前设置了 default-volumes-to-fs-backup，那么即使快照失败，文件级备份也会接管。
如果只备份部分命名空间，可以修改 includedNamespaces；也可以使用 excludedNamespaces 排除 kube-system 等无须备份的资源。建议生产环境至少保留每日备份和每周备份两个 Schedule，每日备份 TTL 设为 7 天，每周备份 TTL 设为 30 天，这样既能控制对象存储成本，又有较长时间的回退窗口。
创建完 Schedule 后，可以用 kubectl get schedules -n velero 查看，也可以手动触发一次备份验证配置：
velero backup create manual-backup-$(date +%Y%m%d%H%M%S) --from-schedule daily-backup velero backup get
当 Manual 备份状态显示 Completed 时，说明对象存储写入和快照流程都没有问题。如果一直卡在 InProgress，可以通过 velero backup describe 查看具体错误，常见原因包括对象存储权限不足、CSI 快照驱动未安装、或节点代理 Pod 未就绪。
四、从定时备份恢复数据
恢复操作可以按整个 Backup 恢复，也可以只恢复某个命名空间或某类资源。发生误删 Namespace 时，最直接的方式是按备份名恢复整个命名空间：
velero restore create --from-backup daily-backup-20250101020000 \ --include-namespaces production velero restore get velero restore describe restore-name
如果需要恢复到不同集群或不同命名空间，可以使用 namespaceMapping 和 restoreOnly 参数。例如把 production 恢复为 staging：
velero restore create --from-backup daily-backup-20250101020000 \ --namespace-mappings production:staging \ --restore-only-configmaps,secrets,deployments
恢复持久卷时有一个重要限制：如果原集群已经不存在，或者云厂商快照不可用，快照恢复会失败。这时应确保备份时启用了文件级备份，并在恢复时使用 --restore-volumes=true。文件级备份会把数据还原到新建的 PV 中，虽然速度慢一些，但跨集群、跨存储类都能恢复。
另一个容易忽略的点是 CRD 恢复顺序。Velero 会先恢复 CRD 定义，再恢复自定义资源实例，但如果某些 CRD 的 Webhook 在恢复时还未就绪，可能导致资源校验失败。遇到这种情况，可以先停掉相关 Webhook 或使用 Velero 的 restore hooks 延迟恢复。
五、监控告警与日常维护
定时备份最怕的是“以为在备份，其实早已失败”。所以光创建 Schedule 不够，还要把备份状态接入监控。Velero 从 1.7 开始暴露 Prometheus 指标，包括 velero_backup_success_total、velero_backup_failure_total、velero_backup_last_success_timestamp 等。可以在 Prometheus 中配置告警，当某个 Schedule 超过 24 小时没有成功备份时通知运维。
告警规则示例如下：
groups:
- name: velero-backup
rules:
- alert: VeleroBackupFailed
expr: increase(velero_backup_failure_total[1h]) > 0
for: 5m
labels:
severity: critical
annotations:
summary: "Velero 备份失败"
- alert: VeleroNoRecentBackup
expr: time() - velero_backup_last_success_timestamp > 86400
for: 1h
labels:
severity: warning
annotations:
summary: "Velero 超过一天没有成功备份"
日常维护还包括定期清理过期备份、关注对象存储容量、测试恢复流程。很多团队只在灾难发生后才发现恢复脚本有问题，因此建议每月至少做一次恢复演练。演练不需要真的破坏生产环境，可以恢复到隔离命名空间或临时集群，验证资源完整性和数据一致性。
如果集群规模较大，备份过程中产生的 API 请求可能会对 kube-apiserver 造成压力。可以通过设置 --resource-timeout、--item-operation-timeout 等参数控制单次操作超时，也可以把备份时间安排在业务低谷。对于超过几千个资源的集群，建议拆分多个 Schedule 按命名空间分别备份，避免单个 Backup 任务过大导致超时。
最后提醒一点，备份数据已经进入对象存储后，需要保护好对象存储的访问密钥和桶策略。不要让 Velero 使用的 IAM 用户拥有删除桶的权限，同时开启对象存储版本控制或对象锁，防止误删备份或勒索软件破坏。Velero 本身支持备份加密，但密钥管理要单独规划。
VeleroKubernetes定时备份修改时间：2026-10-06 16:17:56