必须使用 csi volumesnapshot + volumesnapshotclass 实现存储层一致性备份，mysqldump 或 kubectl cp 无法保证崩溃一致性；需 kubernetes v1.20+、csi 驱动就绪、底层存储支持快照，并在 mysql 执行 flush tables with read lock 后创建快照，待 readytouse: true 再解锁，deletionpolicy 应设为 retain。
直接结论：必须用 CSI VolumeSnapshot + VolumeSnapshotClass，不能靠 mysqldump 或 kubectl cp 替代——前者备份的是存储层一致性状态，后者只管文件或逻辑数据，无法保证崩溃一致性。
VolumeSnapshot 要求 Kubernetes 版本和 CSI 驱动都到位
低于 v1.17 的集群不支持原生快照 API；v1.20+ 才进入 GA 状态，推荐使用。光有版本不够，还必须确认：
-
kubectl get volumesnapshotclasses有输出，且driver字段匹配你后端（如ebs.csi.aws.com、rook-ceph.rbd.csi.ceph.com） -
kubectl get pods -n kube-system | grep snapshot能看到snapshot-controller和cspi-*（CSI 插件实例）正常运行 - 底层存储（如 AWS EBS、Ceph RBD）本身支持快照，并已在 CSI Driver 配置中启用
allowVolumeExpansion: true和快照相关功能开关
MySQL 场景下必须先冻结写入再触发快照
快照是存储层操作，不感知数据库事务状态。若在写入过程中打快照，可能产生损坏的 InnoDB 表空间。正确做法是：
- 在
CronJob容器中先连接 MySQL 执行FLUSH TABLES WITH READ LOCK（注意：需高权限账号，且会阻塞写） - 立刻调用
kubectl apply -f创建VolumeSnapshot对象 - 快照创建成功后（
kubectl get volumesnapshots -o wide显示ReadyToUse: true），再执行UNLOCK TABLES - 不要在快照命令前后加 sleep —— 快照创建是异步的，
ReadyToUse字段才是唯一可靠信号
VolumeSnapshotClass 的 deletionPolicy 别设成 Delete
默认值是 Delete，意味着删除 VolumeSnapshot 对象时，底层存储快照也会被销毁。生产环境务必改为：
-
deletionPolicy: Retain：保留底层快照，仅释放 Kubernetes 对象引用 - 否则一旦误删
VolumeSnapshot，快照就永久丢失，且无回收站 - 配合 RBAC 限制非管理员对
volumesnapshots的delete权限，比改策略更关键
快照本身不等于可恢复的数据库——它只是 PV 数据块的一致性副本。后续恢复需通过 VolumeSnapshotContent 绑定新 PVC，再挂载给 MySQL Pod 启动；但 InnoDB 启动时仍会做 crash recovery，所以快照前的 READ LOCK 不可省略。这个环节最容易被跳过，结果就是“备份成功、恢复失败”。
