必须用qcow2格式磁盘+virsh外部快照，且MySQL快照前须执行FLUSH TABLES WITH READ LOCK；否则InnoDB表空间大概率损坏。因raw不支持快照功能，无CoW元数据结构，qemu-img snapshot -c对其无效，恢复后常报ibdata1锁错或表空间丢失。
直接回答：在 KVM 私有云中对 MySQL 做磁盘级备份与快照，必须用 qcow2 格式磁盘 + virsh 外部快照，且 MySQL 必须在快照前执行 FLUSH TABLES WITH READ LOCK；否则备份出来的数据文件大概率损坏，尤其是 InnoDB 表空间无法恢复。
为什么不能对 raw 格式磁盘做快照？
raw 格式不支持快照功能，virsh snapshot-create 会报错：operation failed: domain does not support snapshots。KVM 的快照机制依赖 qcow2 的写时复制（CoW）元数据结构，raw 是纯二进制镜像，没有快照头、L1/L2 表等必要信息。
常见误操作是直接对运行中的 raw 虚拟机执行 qemu-img snapshot -c —— 这个命令只适用于 qcow2，对 raw 无效，且不会报错，但生成的“快照”实际是空壳，恢复后 MySQL 启动失败，报错如：InnoDB: Unable to lock ./ibdata1 error: 11 或 Tablespace is missing for table 'xxx'。
- 确认格式：用
qemu-img info /var/lib/libvirt/images/mysql-vm.qcow2查看输出中file format:是否为qcow2 - 转换方法（需关机）：
qemu-img convert -f raw -O qcow2 mysql-vm.img mysql-vm.qcow2 - 转换后务必修改虚拟机 XML 配置：
外部快照 vs 内部快照：选哪个？
选 外部快照（external snapshot）。内部快照把快照数据和 base 镜像混在一个 qcow2 文件里，长期使用会导致 I/O 性能下降、碎片严重，且无法单独备份快照层——而你要的是可离线归档、可跨主机恢复的备份点。
创建外部快照的正确姿势是：
- 先停写：
mysql -e "FLUSH TABLES WITH READ LOCK;"（注意：该锁会阻塞所有 DML，需在业务低峰期） - 记录位点：
mysql -e "SHOW MASTER STATUS\G"，保存File和Position，用于后续 binlog 恢复 - 立即创建快照：
virsh snapshot-create-as --domain mysql-vm --name snap-$(date +%Y%m%d-%H%M) --disk-only --atomic --quiesce - 解锁：
mysql -e "UNLOCK TABLES;"
关键参数说明：--disk-only 表示只快照磁盘、不保存内存状态；--atomic 确保多磁盘快照原子性（MySQL 若挂了多个磁盘如 /var/lib/mysql 和 /var/log/mysql，必须加）；--quiesce 尝试调用 fsfreeze（需 guest agent 支持），进一步降低文件系统不一致风险。
快照后如何安全归档与验证？
快照本身只是元数据指针，真正要备份的是 base 镜像 + 所有快照链文件。例如 base 是 mysql-vm.qcow2，快照生成 mysql-vm.qcow2.1、mysql-vm.qcow2.2，三者缺一不可。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
归档步骤：
- 用
qemu-img info --backing-chain mysql-vm.qcow2.2查清完整依赖链 - 停止虚拟机：
virsh shutdown mysql-vm（避免快照链被写入污染） - 打包整个链：
tar -cf mysql-snap-$(date +%F).tar mysql-vm.qcow2 mysql-vm.qcow2.1 mysql-vm.qcow2.2 - 校验一致性：
qemu-img check -r all mysql-vm.qcow2.2（返回 0 表示无错误）
最容易被忽略的一点：不要只备份最新快照文件。如果 base 镜像损坏或丢失，所有快照都失效——因为 qcow2 快照是差量存储，不是全量副本。
恢复时最常踩的坑
恢复不是简单 virsh snapshot-revert 就完事。MySQL 数据目录若被覆盖，权限、SELinux 上下文、AppArmor profile 全部丢失，启动会卡在 Starting MySQL database server mysqld 不动。
安全恢复流程：
- 先停服务：
systemctl stop mysql（宿主机上不用管，但虚拟机内必须停） - 挂载快照镜像：
guestmount -a mysql-vm.qcow2.2 -m /dev/sda1 /mnt/snap（假设 MySQL 数据在/var/lib/mysql） - 同步数据：
rsync -av --delete /mnt/snap/var/lib/mysql/ /var/lib/mysql/（注意末尾斜杠） - 重置权限：
chown -R mysql:mysql /var/lib/mysql；若有 SELinux，执行restorecon -Rv /var/lib/mysql - 启动前检查：
mysqld --validate-config，再systemctl start mysql
最后强调：快照只是物理备份手段，它不能替代逻辑备份（如 mysqldump --single-transaction）。遇到误删表、SQL 注入等逻辑错误，快照无能为力；只有结合 binlog 解析，才能实现精确到秒的 PITR（Point-in-Time Recovery）。
