Velero文件系统备份，没有云厂商快照也能保住PV数据：完整上手路径

Velero文件系统备份没有云厂商快照也能保住PV数据完整上手路径【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/veleroVelero 的文件系统备份FSBFile System Backup不走快照而是直接从节点文件系统把 PVPersistent Volume可以理解为集群里的一块硬盘里的文件读出来、传到对象存储。你的存储不支持云厂商快照——NFS、EFS、本地盘甚至 emptyDir——这条路就是主要选项。读完本文你能独立完成一次完整的 PV 数据备份与恢复并提前避开最常见的 5 个翻车点。恢复全绿数据库却起不来先说两个真实场景都发生在一切看起来正常之后。场景一velero restore describe里全是 Completed零警告。PostgreSQL 的 Pod 起来却立刻崩溃日志里是FATAL: data directory /var/lib/postgresql/data/pgdata has wrong ownership。数据其实已经落盘丢的是文件属主。根因在于某些存储强制了uid/gid的 SMB、blobfuse、gcsfuse 之类根本不保存每文件属主恢复时 Velero 执行 chown 会返回成功但什么都没改而且全程没有任何报错。场景二更普遍你的存储是 NFS 或 EFS快照这条路从第一天就不通。备份时卷数据被直接跳过你恢复出来的是一个空壳。⚠️ 两个问题指向同一个判断你的存储配的是哪种备份路线。快照路线依赖云厂商或 CSI 插件对块存储的支持一致性最好但适用面窄文件系统路线什么卷都能读代价是数据从运行中的文件系统捕获一致性弱于快照。选错路线后面所有步骤都白做。文件系统路线是怎么工作的FSB 的分工是这样的Velero 服务端为每个要备份的卷创建一个PodVolumeBackup任务每个节点上的 node-agent部署在 DaemonSet 里的常驻代理负责本节点上的卷收到任务后拉起一个 data moverVelero 临时创建的搬运 Poddata mover 里的 kopia一个开源备份库负责去重和增量从宿主机挂载目录读数据写进对象存储里的 kopia 仓库。备份仓库按 namespace 隔离每个 namespace 一个。恢复方向相反。关键细节是Velero 会给被恢复的 Pod 额外注入一个 init 容器它死等所有卷的数据写入完成才放行之后主容器才启动——这就是数据库先启动、数据后落盘这类竞态不会发生的原因。完整的机制描述在仓库的 site/content/docs/main/file-system-backup.mdnode-agent 的就绪检查与调度逻辑在 pkg/nodeagent/。三步跑通文件系统备份第一步带 node-agent 安装 Velero前提是 Kubernetes 1.16 以上且开启 MountPropagation。安装时加一个标志位# --use-node-agent 会在每个节点部署常驻代理FSB 完全依赖它 velero install --use-node-agent执行kubectl get ds -n velero看到node-agent一行且 Pod 全部 Ready即代表部署成功。第二步告诉 Velero 要备份哪些卷FSB 有两种发现模式逐个标注opt-in和默认全备、单独排除opt-out。新手建议用更可控的 opt-in在 Pod 上加注解值是 Pod spec 里的卷名# pvc-volume 是 spec.volumes 里的卷名 # 用 Deployment 管理 Pod 的话把注解直接写进 pod template 即可 kubectl -n foo annotate pod/sample backup.velero.io/backup-volumespvc-volume如果希望所有卷默认走 FSB安装时加--default-volumes-to-fs-backup。注意走 FSB 的卷不会再被快照重复备份两条路线对同一个卷是互斥的。第三步执行备份看卷级任务# 创建备份卷的 FSB 任务由第二步的注解驱动 velero backup create nginx-fs --include-namespaces foo备份对象本身完成不代表卷数据完成要看卷级任务一个卷一条记录kubectl -n velero get podvolumebackups -l velero.io/backup-namenginx-fs每行 STATUS 都变成Completed数据才算真正落进仓库仓库本身可以用velero repo get核对每个 namespace 一个。恢复多出来一个 init 容器# 恢复注入的 init 容器会等所有卷写完数据才放行应用 velero restore create --from-backup nginx-fs # 查卷级恢复任务全部 Completed 且应用 Pod 转 Running 即成功 kubectl -n velero get podvolumerestores -l velero.io/restore-namenginx-fs卡住时看状态机每个卷任务的推进路径是固定的New → InProgress → Uploading终态为 Completed / Failed / PartiallyFailed。对照排查任务停在New通常是 node-agent 没就绪查kubectl get pods -n velero进入Failed看velero backup describe的警告和 node-agent Pod 日志长时间InProgress留意超时参数——fs-backup-timeout默认 4 小时大卷可以用--parallel-files-upload调高文件级并发。避坑清单五个真实翻车点孤儿 PVC没有 Pod 挂载备份出来是空的→ FSB 从 Pod 挂载点读数据没有 Pod 就没有可读路径 → 先起一个挂上该 PVC 的 busybox/alpine 空转 Podstaging pod再执行备份。恢复 Completed应用却报属主错误起不来→ 挂载恒定身份类存储上 chown 静默空转 → 在 Pod 内执行mount | grep -E cifs|fuse|nfs确认挂载参数Azure Files SMB 改用idsfromsid,modefromsid挂载数据库类应用直接避开 FUSE 类存储。hostPath 卷被跳过→ FSB 不支持 hostPathlocal 类型的 PV 则支持 → 换成 PVC 或 local 卷。增量备份并不比全备快多少→ kopia 靠分块扫描找差异单个大文件典型是数据库文件扫描开销大 → 超大单文件库把 FSB 当作兜底主路线仍走快照或接受首次全备的耗时。容器开了 ReadOnlyRootFilesystem备份直接失败→ kopia 需要写udmrepo和.cache两个缓存目录只读根文件系统会挡住 mkdir → 给这两个目录挂 emptyDir 卷绕开根文件系统。性能与并发调优的完整参数仓库里有专门文档site/content/docs/main/performance-guidance.md卷数据的读写逻辑在 pkg/podvolume/。把这套流程先在测试集群完整跑一遍重点核对上面五个坑点再上生产数据。限制条件与边界情况的完整清单延伸阅读里都有延伸阅读site/content/docs/main/file-system-backup.mdsite/content/docs/main/node-agent-concurrency.mdsite/content/docs/main/performance-guidance.md【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考