lvcreate 创建快照必须指定原逻辑卷的绝对路径，如 /dev/vg01/lv_data；快照是写时复制视图，大小建议为预期变更量的20%～30%，需先检查文件系统并卸载原lv后才能安全挂载或合并。
lvcreate 创建快照时必须指定原逻辑卷的绝对路径
快照不是独立文件系统，而是 LVM 层面对原 lv 的写时复制（COW）视图。如果只写 lvcreate -s -n snap_lv origin_lv，LVM 会默认在当前卷组里找同名 LV —— 但很可能找不到，尤其当原 LV 在非默认 VG 或路径含 VG 名时，直接报错 Logical volume "origin_lv" not found。
正确做法是显式带上卷组名和斜杠前缀：
-
lvcreate -s -n snap_data /dev/vg01/lv_data（推荐，明确指向） - 不要用
lvcreate -s -n snap_data lv_data（依赖当前 VG，易错） - 快照大小建议至少为原 LV 预期变更量的 20%～30%，太小会导致快照失效（
snapshot is full） - 快照本身不占用额外空间，直到原 LV 数据块被修改才开始写入 COW 区域
mount 快照前要先检查文件系统状态
快照是某个时间点的块级副本，但若原 LV 正在被写入且未同步（比如数据库未停机、ext4 未执行 e2fsck -f），直接 mount 快照可能挂载失败或读到不一致数据，典型错误是 mount: wrong fs type, bad option, bad superblock 或日志提示 EXT4-fs error。
安全 mount 流程如下：
SmartB2B 是一款基于PHP、MySQL、Smarty的B2B行业电子商务网站管理系统，系统提供了供求模型、企业模型、产品模型、人才招聘模型、资讯模型等模块，适用于想在行业里取得领先地位的企业快速假设B2B网站，可以运行于Linux与Windows等多重服务器环境，安装方便，使用灵活。 系统使用当前流行的PHP语言开发，以MySQL为数据库，采用B/S架构，MVC模式开发。融入了模型化、模板
- 确认原 LV 已卸载，或处于只读状态（如数据库已 flush 并
lvs -o +seg_monitor查看无活跃 I/O） - 运行
e2fsck -f /dev/vg01/snap_data（ext4/xfs_repair 对应 xfs）—— 即使显示 clean，也强制检查元数据一致性 - 再
mount /dev/vg01/snap_data /mnt/snap；xfs 文件系统必须用-o nouuid参数避免 UUID 冲突 - 快照挂载后禁止写入：任何写操作都会破坏 COW 机制，LVM 会立即禁用该快照
lvconvert --merge 要求快照已卸载且原 LV 处于非活动状态
合并快照回原 LV 是恢复数据的常用操作，但 lvconvert --merge 不是“覆盖写入”，而是把快照中保留的旧块逐个拷回原 LV —— 这要求原 LV 当前不能被任何进程打开，否则报错 Cannot merge when logical volume is open。
实操要点：
- 先
umount /dev/vg01/snap_data，再lvchange -an /dev/vg01/lv_data（关闭原 LV） - 执行
lvconvert --merge /dev/vg01/snap_data；注意：命令目标是快照 LV，不是原 LV - 合并成功后，快照自动删除，原 LV 恢复到快照创建时的状态
- 若原 LV 正在使用（比如根分区），只能重启进 rescue 环境再操作；在线合并仅支持缓存型快照（cache pool），普通快照不支持
快照生命周期管理容易忽略的三个硬限制
LVM 快照不是无限可用的备份手段，它受内核和工具链的底层约束，很多问题直到出事才暴露：
- 单个 LV 最多支持 1 个活跃快照（老版本内核如 3.10 严格限制，新内核放宽但不推荐多快照共存）
- 快照 COW 表大小由
lvcreate -L指定，一旦耗尽，快照自动变为Inactive状态，无法 mount 也无法 merge，只能丢弃（lvremove） - 使用
lvs -o +snap_percent监控使用率，>85% 就该预警；但snap_percent不反映碎片，实际 COW 空间可能更早耗尽 - 快照不能嵌套（即不能对快照再建快照），
lvcreate -s对快照 LV 执行会直接拒绝
快照本质是临时一致性视图，不是替代备份的方案。它的可靠性高度依赖原 LV 的静默窗口长度和 COW 空间预估精度，这两点最容易被当成“只要建了就稳了”。
