用快照重建数据卷
恢复不是把原卷回滚，而是以快照为数据来源创建一个全新的卷声明。存储驱动会依据快照内容准备好一份新数据，再挂载给新的工作负载。这样原卷与快照都保持可用，恢复失败也不会破坏现有数据，代价是需要额外的存储空间。
基本信息
| 所属接口组 | 核心接口组中的卷声明对象 |
|---|---|
| 数据来源字段 | 指定快照名称与接口组 |
| 容量要求 | 请求容量不得小于快照容量 |
| 类兼容性 | 存储类需与创建快照的驱动兼容 |
| 结果形态 | 得到一份独立的数据副本 |
典型使用场景
- 数据误删后从快照拉出一份副本挂到临时环境核对
- 发布回退：用快照创建新卷，替换到旧版本工作负载
- 搭建测试环境：从生产快照复制数据，避免直接从生产挂载
- 数据库升级失败后快速拉起一份历史数据
- 迁移前先在目标环境验证数据可用性
从快照恢复卷声明
从快照恢复卷声明
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql-data-restore
namespace: prod
spec:
storageClassName: fast-ssd # 需与快照驱动兼容
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 100Gi # 不得小于快照容量
dataSource:
name: mysql-snap-1012
kind: VolumeSnapshot
apiGroup: snapshot.storage.k8s.io验证
验证
kubectl get pvc mysql-data-restore -n prod # 是否绑定成功
kubectl describe pvc mysql-data-restore -n prod | grep -i snapshot # 数据来源确认
kubectl get volumesnapshot mysql-snap-1012 -n prod # 快照是否就绪
kubectl get pod -n prod -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}' | head字段与状态读法
| 字段或状态 | 含义 | 注意点 |
|---|---|---|
| 数据来源 | 指定快照与接口组 | 写错会创建出空白卷 |
| 请求容量 | 新卷容量 | 小于快照容量会被拒绝 |
| 存储类 | 决定由哪个驱动供给 | 与快照不是同一驱动时无法恢复 |
| 绑定状态 | 卷是否创建完成 | 长期等待说明驱动侧异常 |
恢复出的卷是一份独立副本，与快照及原卷互不影响。核对数据时可以先挂到一个临时副本上检查，确认无误再替换正式工作负载。
恢复前确认原卷没有并发写入：如果旧实例仍在写数据，随后切换回恢复的卷会造成数据分叉，比单纯停服更难处理。