快照空间耗尽导致“snapshot is full”错误，因cow机制下原lv写入需额外存储旧数据；创建时须显式指定足够大小（如原lv的20%），并及时监控snap%、激活快照、避免长期留存。
lvcreate -s 创建快照时为什么报错 snapshot: snapshot is full
快照空间耗尽是 LVM 备份中最常遇到的“假失败”——不是命令写错了，而是预留空间不够。LVM 快照用的是写时复制（COW），原逻辑卷（LV）每改一个块，快照就得存一份旧数据；如果原 LV 写入频繁或快照保留太久，snapshot 就会填满。
实操建议：
- 创建时必须显式指定大小，
lvcreate -s不设-L会默认用 100% 空闲 PE，但实际往往不够；保守起见，对读多写少的数据库备份，按原 LV 预估写入量的 20% 分配（例如原 LV 100G，快照给 20G） - 监控快照使用率：用
lvs -o +snap_percent查看SNAP%列，超过 85% 就该考虑合并或丢弃 - 别把快照当长期归档——它不是副本，只是时间点视图；超过 24 小时未使用的快照，建议
lvremove掉，避免拖慢原 LV 性能
从快照恢复数据：直接 mount 还是 dd 恢复？
快照本身是只读的（除非你加了 --permission rw，但不推荐），不能直接当生产盘用。恢复分两种场景：单文件误删和整卷回滚。
实操建议：
- 恢复单个文件：先
mount /dev/vgname/snapname /mnt/snap，再从/mnt/snap拷贝所需文件，完事umount并lvremove - 整卷回滚：必须停掉对应服务，然后用
lvconvert --merge—— 注意：只能在快照未挂载、且原 LV 处于非激活状态（即lvchange -an后）才能执行；合并后快照自动消失，原 LV 回到快照创建时的状态 - 别用
dd if=/dev/vgname/snapname of=...做“镜像备份”，快照设备不是稳定块设备，dd 中途可能因 COW 填满而失败
快照备份脚本里漏掉 lvchange -ay 导致恢复失败
很多自动化脚本只记得 lvcreate -s，却忘了快照创建后默认是 inactive 状态，mount 会报 mount: wrong fs type, bad option, bad superblock —— 实际就是设备没激活。
实操建议：
- 创建快照后立刻执行
lvchange -ay /dev/vgname/snapname，否则mount必败 - 脚本中建议加检查：用
lvs -o+attr看第三列，输出里应有owi-a-s---（其中a表示 active）；若为owi---s---，说明没激活 - 如果用 ext4，还要确认内核支持快照设备 mount（4.12+ 基本都行），老系统（如 RHEL6）需额外加载
dm-snapshot模块
为什么 lvremove 快照前要确保没挂载也没被 merge？
lvremove 报 Can't remove open logical volume 或静默失败，八成是因为快照还在被使用：要么挂载着，要么已在 merge 队列里但原 LV 没重启。
实操建议：
- 删之前先跑
lsof +D /mnt/snap或findmnt | grep snapname，确认无挂载点 - 如果做过
lvconvert --merge，得等下次 reboot 才真正生效；此时lvs仍显示快照存在，但 attr 里会有m标记（如owi-a-m---），这时强行lvremove会失败 - 紧急清理：可先
lvchange -an /dev/vgname/snapname关闭，再lvremove；但若已标记 merge，必须重启，否则原 LV 数据可能不一致
快照机制看着简单，但 COW 的触发时机、merge 的延迟生效、以及 inactive/active 状态切换，这几个点一错，备份就变成障眼法。真出问题时，先看 lvs -o+attr,+snap_percent，比翻日志快得多。
