快照创建失败常见于逻辑卷未激活或底层设备不支持cow元数据格式；需确认vg元数据为lvm2、lv已激活、快照大小≥100mb且显式指定-l和--name参数，禁用--permission r与--noudevsync。
快照创建失败：提示 snapshot: Invalid argument
常见于逻辑卷未激活或底层设备不支持写时复制（COW）元数据格式。LVM 默认用 lvm2 格式，但某些旧内核或精简配置的系统可能仍依赖已弃用的 lvm1 元数据，而它不支持快照。
- 先确认卷组元数据格式：
vgdisplay -v <vg_name></vg_name>，检查输出中Metadata format是否为lvm2 - 确保源逻辑卷处于激活状态：
lvscan | grep -i active，若显示inactive，运行lvchange -ay <vg_name>/<lv_name></lv_name></vg_name> - 快照大小不能为 0，且建议不低于源 LV 写入量的 20% —— 小于 100MB 的快照极易因元数据填满而自动失效
lvcreate --snapshot 的关键参数取舍
不是所有参数都该加，加错反而导致快照不可用或行为异常。
-
-L指定快照大小，必须显式给出；-l（按 PE 数）容易误算，不推荐日常使用 -
--name必须指定，否则默认名含时间戳，难追踪；名字不能含下划线以外的特殊字符，否则lvremove可能报错 - 不要加
--permission r：只读快照无法挂载为 ext4/xfs，会卡在mount: wrong fs type - 避免用
--noudevsync：跳过 udev 同步会导致/dev/mapper/下设备节点缺失，后续mkfs或mount失败
快照挂载后内容“没变”或“变乱”
这不是数据损坏，而是快照语义和挂载时机的理解偏差。LVM 快照是写时复制（CoW），只捕获创建时刻的块状态，且对后续写入的响应有延迟窗口。
- 源 LV 在快照创建后立即被修改（比如日志刷盘、数据库 checkpoint），快照里对应块可能已被覆盖，表现为“看不到预期旧数据”
- 挂载快照前务必运行
vgchange -ay <vg_name></vg_name>，否则设备未就绪，mount可能静默失败或挂载空文件系统 - ext4/xfs 等日志文件系统在快照中不保证日志一致性 —— 若需可靠备份，应在快照创建前卸载源 LV，或配合应用层冻结（如
xfs_freeze -f）
快照自动失效后怎么救？
当快照 COW 空间耗尽，LVM 会将其状态设为 Invalid，lvdisplay 显示 snapshot status: Invalid，此时无法读取任何数据。
- 没有“恢复”手段 ——
lvconvert --merge对无效快照无效，lvremove是唯一安全操作 - 可尝试用
dd if=/dev/<vg_name>/<snapshot_lv> of=snapshot.img bs=4K</snapshot_lv></vg_name>提取原始块，但多数情况下前几 MB 就是元数据头，后续全是零 - 预防比抢救重要：监控快照使用率，用
lvs -o+data_percent,metadata_percent定期检查，把 >85% 的快照列为高危
快照不是备份替代品，它的生命周期天然短暂，依赖空间配额和写入模式。哪怕只读场景，也要盯着 data_percent——这个数字涨得比你预期快得多。
