LVM快照无法对物理磁盘本身做秒级冷备份，仅支持逻辑卷（LV）的瞬时、块级一致备份，需确保全部业务数据位于LVM管理的LV上，并配合数据库静默（如FLUSH TABLES WITH READ LOCK）与合理快照空间规划。
一、必须满足的硬性前提
快照只认LV，不认物理盘。跳过这步，后续全白忙：
-
所有业务数据必须挂载在LVM逻辑卷上：运行
df -h /data /var/lib/mysql /opt/app，确认路径对应设备是/dev/mapper/vgname-lvname或/dev/vgname/lvname； -
/boot 不能依赖快照：GRUB2通常不支持从LVM快照启动，需单独用
rsync -aHAX /boot/ /backup/boot_$(date +%Y%m%d)/或dd if=/dev/sda1 of=/backup/boot_sda1.img bs=4M备份； -
卷组（VG）要有足够空闲PE：执行
vgdisplay vgname | grep "Free PE"，确保剩余空间 ≥ 你计划分配的快照大小（单位为PE，1PE通常4MB）； -
内核模块已加载：检查
lsmod | grep dm_snapshot，若无输出则运行modprobe dm-snapshot。
二、实现“秒级+块级一致”的核心操作
秒级来自元数据创建，一致性来自数据库/应用层配合。两者缺一不可：
-
MySQL场景：先执行
mysql -e "FLUSH TABLES WITH READ LOCK;"（毫秒级阻塞），立即运行lvcreate -L 2G -s -n mysql_snap_$(date +%Y%m%d_%H%M) /dev/vgdata/mysql_lv，再立刻mysql -e "UNLOCK TABLES;"； -
PostgreSQL场景：用
psql -c "SELECT pg_start_backup('lvm_snap', true);"→ 创建快照 →psql -c "SELECT pg_stop_backup();"； -
纯文件系统（如/var/www）：若无数据库事务，可跳过锁，但需确保无进程正在写入关键目录（用
lsof +D /var/www检查）； -
不要用 --cached 或后台刷新替代停写：
sync && echo 3 > /proc/sys/vm/drop_caches只清缓存，不解决正在提交的InnoDB页问题。
三、快照空间不是“越大越好”，而是“刚好够用”
空间不足会导致快照瞬间 invalid，备份失败无声无息。按实际写入压力算，别靠经验估：
- 公式：快照大小 = （每秒平均写入量 × 预估备份耗时）× 1.5；
-
测写入量示例：用
iostat -xmd 1 5 | awk '/sda/ {print $10}' | tail -1看 sda 的写入KB/s，或查MySQL的SHOW GLOBAL STATUS LIKE 'Innodb_data_written';增量； -
监控占用率：创建后立即运行
watch -n 10 'lvs -o +data_percent | grep mysql_snap'，一旦 >85%，就要扩空间（lvextend -L +500M /dev/vgdata/mysql_snap_20260524）或终止备份； - 典型参考值：中小MySQL实例（日增1GB），8分钟rsync备份 → 建议2G快照；高写入OLTP库 → 建议4–6G起步。
四、备份导出与清理闭环（避免快照长期挂载）
快照只是“时间点指针”，必须挂载读取并导出，且不能长期存在：
-
只读挂载防误操作：执行
mkdir -p /mnt/snap_ro && mount -o ro,nouuid /dev/vgdata/mysql_snap_20260524 /mnt/snap_ro； -
用rsync导出（保留权限/ACL/xattr）：运行
rsync -aHAX --delete /mnt/snap_ro/ /backup/mysql/20260524/； -
卸载后立即删除快照：完成校验（如
du -sh /backup/mysql/20260524对比原LV大小）后，执行umount /mnt/snap_ro && lvremove -f /dev/vgdata/mysql_snap_20260524； - 严禁长期保留快照：COW机制会持续放大IO，超过2小时未清理可能拖慢宿主LV性能，且增加空间爆满风险。
