Linux LVM 快照使用实践

快照创建失败常见于逻辑卷未激活或底层设备不支持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——这个数字涨得比你预期快得多。