快照写满后自动失效，原LV数据完好无损；仅快照中创建后被修改的旧版本文件内容及历史只读视图不可恢复，无法追溯具体变更文件。
Linux LVM 快照写满后，**快照本身会自动失效（invalid），但原逻辑卷（LV）的数据完全不受影响，不会丢失**。真正“丢失”的不是原始数据，而是快照中尚未同步的、在快照生命周期内被修改过的旧版本数据——这部分数据因快照空间耗尽而无法再保存，导致快照不可用，也就无法回滚或读取当时的文件状态。
如何判断快照是否已写满失效
执行以下命令检查快照状态：
- lvs -o +snap_percent,origin,lv_attr：查看快照使用率（snap_percent 列为 100% 或显示 invalid）和属性（lv_attr 中若含 I 表示 invalid）
- lvs --all | grep snapshot：快速过滤快照，观察状态列是否为 sri-a-s---（i 表示 invalid）
- dmesg | tail -20：内核日志中常有类似 snapshot: Invalidating snapshot ... due to overflow 的提示
哪些“数据”算作已丢失？明确范围
所谓“丢失”，仅指以下两类信息不可恢复：
- 快照创建后、失效前被修改过的文件旧版本内容：例如快照创建时 /home/user/doc.txt 是 v1，之后被覆盖为 v2；快照失效后，v1 就永久不可访问
- 快照挂载后能读取的只读视图（即历史一致性镜像）：失效后无法 mount，也无法用 dmsetup 或 lvconvert 恢复该时间点视图
- 注意：原始 LV 上当前所有数据（v2 及之后版本）完好无损，未受任何影响
能否事后追溯具体哪些文件发生了变更？
不能直接从失效快照中获取——因为快照元数据已损坏或清空。但可借助外部机制辅助推测：
- 若快照曾被挂载并启用 inotify 或 auditd 监控，可查对应日志（如 /var/log/audit/audit.log）定位变更路径
- 若启用了 rsync + 日志 或 etckeeper 等变更追踪工具，可比对时间窗口内的差异
- 原 LV 上可通过 debugfs（ext系列） 或 xfs_info + xfs_db（XFS） 查看 inode 修改时间（mtime/ctime），结合快照生命周期粗略筛选高概率变更文件
预防比判断更重要：避免再次发生
- 创建快照时预留足够空间：至少为预计变更数据量的 20–30%（例如活跃数据库 LV 每天写入 5GB，快照建议 ≥2GB）
- 监控快照使用率：用 cron + lvs --noheadings -o snap_percent 定期告警（如 >85% 触发）
- 设置自动清理策略：快照仅用于短期操作（如升级前备份），完成后立即 lvremove
- 关键场景改用更可靠的方案：如 btrfs/zfs 快照（写时复制+空间动态分配）或应用层逻辑备份
