lvm快照不能单独作为mysql备份，必须配合flush tables with read lock、flush engine logs、记录binlog位点及正确挂载导出；否则恢复时大概率报innodb页损坏。
不能直接用LVM快照当MySQL备份——它只冻结块设备状态，不保证InnoDB页一致性。必须配合FLUSH TABLES WITH READ LOCK + FLUSH ENGINE LOGS + binlog位点记录，否则恢复大概率报InnoDB: Database page corruption。
确认MySQL数据目录是否在LVM逻辑卷上
这是硬性前提，跳过就全白忙。LVM快照只作用于LV，对/dev/sda2或/dev/nvme0n1p1这类物理分区无效。
- 运行
df -h /var/lib/mysql，检查输出中“Filesystem”列是否为/dev/mapper/vgname-lvname或/dev/vgname/lvname - 若显示
/dev/sda2，说明没走LVM——需先停MySQL、用rsync迁移数据到新LV、更新my.cnf中datadir并挂载进/etc/fstab -
/boot永远别指望快照：GRUB2不支持从LVM快照启动，得单独用rsync -aHAX /boot/ /backup/boot_$(date +%Y%m%d)/备份
执行一致性冻结与快照创建（秒级关键操作）
锁表时间必须压缩到秒内，靠的是“先刷盘、再拍快照、立刻解锁”，不是靠等IO自然落盘。
- 先强制刷所有脏页和日志：
mysql -e "FLUSH TABLES WITH READ LOCK; FLUSH ENGINE LOGS; FLUSH LOGS;" - 立刻记录binlog位置：
mysql -e "SHOW MASTER STATUS" > /backup/binlog_$(date +%F_%H%M).txt - 马上建快照：
lvcreate -L 5G -s -n mysql_snap_$(date +%Y%m%d_%H%M) /dev/vgdata/mysql_lv（注意-L是COW空间，不是快照大小上限） - 解锁：
mysql -e "UNLOCK TABLES;"——这步晚于快照创建就失效 - 常见错误：
ERROR 2013 (HY000): Lost connection，基本都是FLUSH ENGINE LOGS漏了或顺序错乱
挂载快照并导出数据（不能直接拷LV设备）
LVM快照本身只是COW元数据引用，/dev/vgdata/mysql_snap这个设备节点不包含完整文件数据，必须挂载后读文件系统。
- 检查快照状态：
lvs -o +attr /dev/vgdata/mysql_snap，确认Attr列第5位是s（snapshot），不是S（suspended）；若为S，先lvchange -ay /dev/vgdata/mysql_snap - XFS快照必须先修复：
xfs_repair -o force_geometry /dev/vgdata/mysql_snap（ext4可跳过） - 只读挂载：
mount -o ro,nouuid /dev/vgdata/mysql_snap /mnt/snap（nouuid防与原卷UUID冲突） - 导出用
tar而非cp：tar -czf /backup/mysql_$(date +%F_%H%M).tar.gz -C /mnt/snap .（-C避免绝对路径） - 严禁在挂载状态下启动
mysqld——会破坏一致性
快照空间规划与失效风险
快照空间不是越大越好，而是刚好够撑过备份窗口。空间耗尽时lvs显示active (invalid)，但不会报错，备份静默失败。
- 估算公式：
快照大小 ≈ 备份窗口内原LV写入量 × 1.2；例如备份过程持续10分钟，平均写入30MB/s，则至少预留30 × 600 × 1.2 ≈ 22G - 监控命令：
lvs -o +data_percent,metadata_percent /dev/vgdata/mysql_snap，重点关注data_percent - 高写入负载下不建议挂载快照超过30分钟——COW导致IO放大，可能拖慢原库
- 备份完成后务必
umount /mnt/snap && lvremove /dev/vgdata/mysql_snap，残留快照会持续占用PE且影响VG性能
真正难的不是命令怎么敲，而是判断“业务写入压力是否稳定”“binlog位点有没有被误删”“XFS快照漏跑xfs_repair”。这些点不盯住，快照建得再快，备份也是废的。
