4. 对象存储与快照后端选型

Velero 的备份数据最终要落到一个“后端存储”上，而卷数据则可能走另一条路径。理解这两条路径的差异，是选型的第一步。Velero 把集群资源（YAML 对象）序列化后写入对象存储，这部分称为 BackupStorageLocation（BSL）；而持久卷里的数据，则通过 VolumeSnapshotLocation（VSL） 调用云厂商快照 API，或通过 Restic/Kopia 以文件级方式读取后同样写入对象存储。因此“对象存储选型”和“卷备份方式选型”是两个独立但需要协同决策的问题。

对象存储接入：统一抽象与差异点

Velero 通过 AWS SDK 兼容的 S3 协议访问绝大多数对象存储，这也是它能同时支持 AWS S3、MinIO、阿里云 OSS、Ceph RGW 等的原因。接入时核心是四类参数：bucket、prefix、region、以及凭证。凭证通常放在一个 Secret 中，键名固定为 cloud，内容是一段 INI 风格的配置：

apiVersion: v1
kind: Secret
metadata:
  name: cloud-credentials
  namespace: velero
type: Opaque
stringData:
  cloud: |
    [default]
    aws_access_key_id=AKIAEXAMPLE123456789
    aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

对于非 AWS 的 S3 兼容存储，需要在 BackupStorageLocation 中显式指定 s3Url，并关闭或调整签名区域。以 MinIO 为例，典型配置如下：

apiVersion: velero.io/v1
kind: BackupStorageLocation
metadata:
  name: minio
  namespace: velero
spec:
  provider: aws
  objectStorage:
    bucket: velero-backups
    prefix: prod-cluster
  config:
    region: minio
    s3ForcePathStyle: "true"
    s3Url: http://minio.storage.svc:9000
  credential:
    name: cloud-credentials
    key: cloud

这里有两个容易踩坑的点。第一，s3ForcePathStyle 必须为 "true"，否则 SDK 会尝试用 bucket.host 形式的虚拟主机寻址，而 MinIO 默认只支持路径寻址。第二，region 对 MinIO 而言只是签名占位符，填任意非空值即可，但若留空，部分 SDK 版本会直接报签名错误。阿里云 OSS 的接入方式与 MinIO 类似，s3Url 填 https://oss-cn-hangzhou.aliyuncs.com，region 填 cn-hangzhou，并保持路径寻址。Azure Blob 与 GCP GCS 则不走 S3 协议，Velero 分别提供 azure 和 gcp 两个 provider，凭证字段也不同：Azure 使用 AZURE_STORAGE_ACCOUNT_ACCESS_KEY，GCS 使用服务账号 JSON 的 GOOGLE_APPLICATION_CREDENTIALS 内容。

CSI 快照、云盘快照与文件系统备份的适用场景

卷备份方式的选择，取决于存储类型、恢复目标（RTO/RPO）、是否跨云以及是否需要细粒度恢复。三者并非互斥，Velero 允许在同一备份中混合使用：对有 VolumeSnapshotClass 的 PVC 走快照，其余走 Restic/Kopia。

CSI 快照是 Kubernetes 原生的卷快照机制，依赖存储驱动实现 CreateSnapshot。它的优势是与 PVC 生命周期解耦、恢复时可直接从 VolumeSnapshot 创建新 PVC，且不占用节点 CPU 去逐文件读取。前提是集群已安装 snapshot-controller 与对应 CSI 驱动，并存在可用的 VolumeSnapshotClass。它适合块存储、数据库类应用，以及 RTO 要求较短的场景。需要注意的是，快照通常与底层存储绑定，跨集群恢复时目标集群必须能访问同一存储后端。

云盘原生快照（如 AWS EBS Snapshot、阿里云云盘快照）由云厂商提供，Velero 通过对应插件调用。它比 CSI 快照更底层，适合尚未支持 CSI 快照的旧集群，或需要利用云厂商快照策略（如生命周期、跨区域复制）的场景。代价是绑定特定云，迁移性差。

文件系统备份（Restic 或 Kopia）不依赖存储快照能力，而是由节点上的 Velero 代理逐文件读取卷内容，去重后写入对象存储。它最大的价值是跨云可移植和细粒度恢复——可以只恢复某个命名空间甚至某个文件。代价是备份速度受文件数量和大小影响，且对节点资源有消耗。对于 NFS、CephFS 等不支持快照的存储，或需要把备份搬到另一朵云的场景，文件级备份几乎是唯一选择。

一个可参考的混合配置示例

假设生产集群在 AWS，部分 PVC 使用 EBS（gp3），部分使用 EFS。EBS 走 CSI 快照，EFS 走 Kopia。BackupStorageLocation 指向 S3，VolumeSnapshotLocation 指向同一区域。备份命令如下：

velero backup create prod-daily \
  --include-namespaces prod \
  --snapshot-volumes=true \
  --default-volumes-to-fs-backup=true \
  --storage-location aws-s3 \
  --volume-snapshot-locations aws-ebs \
  --ttl 720h

其中 --snapshot-volumes=true 表示优先尝试快照，--default-volumes-to-fs-backup=true 表示对没有快照能力的卷自动回退到文件级备份。执行后可用 velero backup describe prod-daily --details 查看每个卷实际走的是 Snapshot 还是 Restic/Kopia，并核对 Phase 是否为 Completed、Errors 是否为 0。若某个 EBS 卷显示 Snapshot 失败而回退到文件级，通常意味着 VolumeSnapshotClass 缺失或 CSI 驱动未就绪，应优先排查这两项，而不是直接接受回退结果。

最后，无论选择哪种后端，都应在正式启用前做一次“备份—删除—恢复”的闭环演练：创建一个带数据的测试 PVC，执行备份，删除命名空间，再从备份恢复，验证数据行数与校验和一致。只有闭环通过，选型才算真正落地。