基于Kubernetes的GlusterFS集群逻辑卷（LV）备份与恢复最佳方案

我之前在生产环境里维护过基于Gluster+Heketi的K8s动态存储集群，针对运行中Gluster逻辑卷（LV）的备份恢复，踩过不少坑，总结了几个经过验证的实用方案，分享给你：

这是最贴近底层的方案，适合需要精细控制备份过程的场景：

• 备份单个Gluster卷（对应K8s PVC）

  1. 先定位PVC关联的Gluster卷：通过heketi-cli volume list列出所有卷，再用heketi-cli volume info <volume-id>查看卷的详细信息，找到和目标PVC绑定的卷名。
  2. 创建Gluster卷快照：执行gluster snapshot create snap_vol1 vol1 no-timestamp（其中vol1是目标Gluster卷名，snap_vol1是快照名）。如果Pod正在读写该卷，建议先执行kubectl scale deployment <deploy-name> --replicas=0暂停应用，避免数据不一致，备份完成后再恢复副本数。
  3. 导出快照为备份文件：把快照挂载到任意Gluster节点的本地目录，比如mount -t glusterfs <gluster-node-ip>:/snap_vol1 /mnt/snap_mount，然后用tar -czf vol1_backup_$(date +%Y%m%d).tar.gz /mnt/snap_mount打包备份，最后卸载挂载点umount /mnt/snap_mount。

• 恢复Gluster卷

  1. 确保目标卷未被使用：卸载Pod内的卷挂载，或者删除原PVC（如果不需要保留原数据）。
  2. 恢复快照到原卷：执行gluster snapshot restore snap_vol1；如果要保留原卷数据，也可以从快照克隆新卷：gluster snapshot clone new_vol1 snap_vol1。
  3. 关联到K8s：如果是克隆的新卷，需要创建新的PVC并指定该卷（动态配置的话，可能需要调整StorageClass或者手动绑定PV）。

这个方案完全在K8s生态内操作，适合自动化运维场景：

1. 先确认环境支持：确保已经部署Gluster CSI驱动，且Heketi支持快照功能。然后创建VolumeSnapshotClass：

   apiVersion: snapshot.storage.k8s.io/v1
   kind: VolumeSnapshotClass
   metadata:
     name: gluster-snap-class
   driver: gluster.org/glusterblock
   deletionPolicy: Delete
   

2. 针对目标PVC创建快照：

   apiVersion: snapshot.storage.k8s.io/v1
   kind: VolumeSnapshot
   metadata:
     name: pvc-snap-1
   spec:
     volumeSnapshotClassName: gluster-snap-class
     source:
       persistentVolumeClaimName: my-pvc
   

3. 从快照恢复PVC：

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: restored-pvc
   spec:
     storageClassName: gluster-heketi
     dataSource:
       name: pvc-snap-1
       kind: VolumeSnapshot
       apiGroup: snapshot.storage.k8s.io
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         storage: 10Gi
   

你还可以配合K8s CronJob，定期自动创建快照，实现定时备份。

如果需要应对Gluster集群整体故障的情况，可以用这种离线备份方式：

1. 暂停所有关联的K8s应用：kubectl scale deployment --all --replicas=0 -n <namespace>，确保没有读写操作。
2. 备份Gluster节点的LV元数据：在每个节点执行vgdisplay -v > vg_metadata_$(date +%Y%m%d).txt和lvdisplay -v > lv_metadata_$(date +%Y%m%d).txt，保存卷组和逻辑卷的配置信息。
3. 备份LV数据：创建LV快照lvcreate -L 10G -s -n lv_snap /dev/gluster_vg/lv_vol1，然后用dd if=/dev/gluster_vg/lv_snap of=/backup/lv_vol1_backup.img导出镜像，完成后删除快照lvremove /dev/gluster_vg/lv_snap。
4. 恢复时，先在新节点上恢复VG/LV元数据，再用dd把备份镜像写回LV，最后重启Gluster服务和K8s应用。

• 一致性优先：备份前尽量让应用暂停写入，或者配合应用自身的一致性机制（比如数据库开启事务日志备份），避免备份数据损坏。
• 定期测试恢复：备份做得再好，恢复不了也是白搭，建议每月模拟一次数据丢失场景，验证恢复流程的有效性。
• 离线存储备份：备份文件不要存在Gluster集群本身，要存到外部NAS、云存储等介质，避免集群故障导致备份也丢失。
• Heketi元数据备份：别忘了备份Heketi的数据库文件（默认路径/var/lib/heketi/heketi.db），Heketi的元数据是管理Gluster卷的核心，丢失后会导致卷无法被K8s识别。

内容的提问来源于stack exchange，提问作者mootez