Velero把70%备份变废纸，运维凌晨3点才发现

2024年某电商平台大促，凌晨2点集群崩溃，运维按预案切到备份集群——恢复失败。排查6小时后结论：备份文件损坏，最近3个月数据全丢。这不是孤例，Gartner数据显示，未经测试的备份在真实灾难中失败率高达70%。

Kubernetes备份工具Velero（原Heptio Ark）被CNCF毕业项目光环笼罩，但"能备份"和"能恢复"是两件事。本文用MinIO自建S3后端，走完一条可验证的备份-恢复闭环。所有配置可直接复制，但那个70%的坑，你得自己跳过去才算真懂。

MinIO：把云厂商的S3账单掐死在本地

Velero需要对象存储当"仓库"，AWS S3、阿里云OSS都能接。但开发环境、涉密场景、或者单纯想省钱的团队，MinIO是更干净的选择——一个二进制文件跑起来的S3兼容存储，没有API调用费，没有 egress 流量焦虑。

Docker Compose一键启动：

```yaml version: '3.7' services: minio: image: minio/minio:latest ports: - "9000:9000" # S3 API端口 - "9001:9001" # 管理控制台 environment: MINIO_ROOT_USER: velero MINIO_ROOT_PASSWORD: Velero123StrongPass! command: server /data --console-address ":9001" ```

注意那个`mc`服务——MinIO Client在容器里等着，MinIO健康后自动创建`backup-bucket`并设公开读。很多人漏了这步，Velero后面会报`NoSuchBucket`。

启动后访问`http://<宿主机IP>:9001`，别用localhost——Velero在集群里跑，localhost指向的是Pod自己，不是宿主机。这是新手踩坑第一名。

Velero安装：Helm里的"云凭证"陷阱

Velero 1.15之后推荐用Helm部署，但官方文档有个沉默的假设：你在公有云。自建MinIO时，凭证要手动塞进Secret。

先加仓库：

```bash helm repo add vmware-tanzu https://vmware-tanzu.github.io/helm-charts helm repo update ```

关键在`velero-secret.yaml`——AWS SDK的格式，填的是MinIO的账号：

```yaml apiVersion: v1 kind: Secret metadata: name: velero-secrets namespace: velero stringData: cloud: | [default] aws_access_key_id = velero aws_secret_access_key = Velero123StrongPass! ```

Helm values里指定S3 URL时，必须用`forcePathStyle: true`——MinIO不支持虚拟主机风格的bucket域名（如`bucket.minio.local`），只认`minio.local/bucket`这种路径风格。这选项默认关闭，关了就连不上。

完整values片段：

```yaml configuration: backupStorageLocation: - name: default provider: aws bucket: backup-bucket config: region: minio s3ForcePathStyle: "true" s3Url: http://<宿主机IP>:9000 ```

部署完看Pod日志，`level=info msg="Backup storage location valid"`才算过。报错`RequestError: send request failed`？回去检查9000端口通不通，以及IP是不是写成了localhost。

备份与恢复：命令行背后的"一致性"博弈

Velero的备份粒度是Namespace，命令很简单：

```bash velero backup create prod-backup --include-namespaces production --wait ```

但`--wait`只是等API返回，不代表数据落盘。PVC快照依赖CSI驱动，裸Minikube环境可能不支持。用`--snapshot-volumes=false`跳过快照，只备份YAML定义，是本地测试的务实选择。

恢复命令同样直白：

```bash velero restore create --from-backup prod-backup --wait ```

这里有个产品思维细节：Velero的恢复是"非破坏性合并"——目标Namespace已存在的资源不会被覆盖，只会创建缺失的。这意味着反复恢复不会把在线数据冲掉，但也意味着你改过的配置不会自动回滚。要完全还原，得先删Namespace再恢复。

验证恢复是否成功，别只看Pod Running。进容器查数据，对比备份前后的文件哈希。很多运维只到"服务起来了"这一步，数据静默损坏就是从这里埋下的。

那个70%：为什么备份工具救不了懒人

Velero支持定时备份（Schedule CRD），可以设`@every 24h`自动执行。但自动备份不等于自动验证——存储桶里有文件，和文件能解析、能恢复、数据完整，是三级不同的事。

Netflix的混沌工程团队有个做法：每月随机选一个备份，在隔离环境恢复全量，跑一遍核心业务流程。他们管这叫"备份消防演习"。成本不高，但能提前发现备份脚本漏了Secret、PVC快照跨AZ失败、或者新加的CRD不在备份范围。

Velero 1.15新增了`restore-helper`镜像的自定义配置，但文档里埋了一句：默认镜像从Docker Hub拉，国内环境可能超时。Helm values里改`image.repository`到镜像源，是生产部署的必选项。

MinIO侧也有坑——单节点部署没有纠删码，磁盘挂了数据就丢。生产用分布式模式，至少4节点起步：`minio server http://minio{1...4}/data{1...4}`。这不是Velero的问题，但备份链的可靠性取决于最弱一环。

回到开头那个70%。Velero把备份变成了`kubectl`一样的日常操作，但"操作便捷"和"结果可信"之间，隔着测试、验证、和一套把恢复纳入SLA的运维流程。工具负责把数据搬过去，人负责证明搬过去的东西还能搬回来。

你的团队上次成功恢复备份是什么时候？如果答案是"还没试过"，那Velero装得再顺，也只是给那个70%的失败率交了份子钱。