经典 LVM 快照是在源逻辑卷上附加写时复制异常存储。lvcreate -s -L 5G -n snap vg/data 请求五 GiB 存储,实际分配还受卷组空闲容量和分配粒度约束。创建时不需要复制整份源卷,但不代表完全没有工作或必然瞬时完成。thin 快照使用另一种共享池机制,不能把经典快照的独立异常存储套到所有 LVM 快照上。

异常存储要覆盖整个保留窗口内发生变化的不同 chunk 及其元数据,包括备份复制期间的写入。突发负载可能比安静时估算更早耗尽容量。经典存储满后快照会失效,读取开始返回错误。应提前观察有效状态和增长趋势,留下扩容或结束备份的时间;只规定一个百分比告警,而没有响应能力与空闲空间,不能形成可靠恢复计划。

异常存储,不是副本

源使用 snapshot-origin 目标,snapshot 则把未变化的源 chunk 与保存的异常组合成视图。直接写快照的数据进入它自己的 COW 设备。对已保存异常的同一 chunk 反复修改,不需要为这份快照再保存一次原始内容。原文一百万次写入、十六个热块却只有十五个异常的数字,没有找回轨迹;若十六个不同 chunk 都写过,就需十六份数据异常,另加元数据。

lvs -a -o lv_name,lv_attr,origin,data_percent,lv_size 展示类型、状态和用量。swi-a-s--- 只是示意,不是所有快照固定的属性串;第五位 I 表示无效快照。告警应覆盖实际增长速率和处理时间。lvextend 需要 VG 中有可分配空间;lvchange --monitor y 只启用监控,自动扩容还依赖 dmeventd、有效扩容策略及足够容量,并不是一个开关就能保证成功。

耗尽即失效

内核文档说明,经典 COW 存储耗尽后会禁用快照并返回错误。lvcreate 手册中按源容量百分之二十创建的命令只是例子,不是通用容量建议。规划要包含 chunk 粒度、元数据、突发变化及完整备份时长。在耗尽之前扩容才有助于维持有效快照;恢复点已经失效时,不能因为 LV 名字仍在,就把它当作内容完整的历史状态。

经典快照溢出时源卷写入通常继续,但这不保证源卷或底层设备不会同时出现其他问题。无效快照不能再作为可用恢复点,却不等于它从未存在;此前已经完成并验证的独立备份可能仍有效。当前快照是否可读,与另一处已完成副本是否完整,应分别核对。不能用夸张的比喻替代这两个不同状态,也不能以源服务还在运行推断快照健康。

合并回滚,以及 thin 如何改变失败形态

lvconvert --merge vg/snap 将持久化 COW 快照合并回源,并消耗该快照。源与快照两个 LV 都未打开时立即开始,否则延后至二者关闭时的激活机会。合并开始后源可以继续服务读写,必要的受影响写入会等待对应 chunk 完成。这里不保证回滚全程无需中断,而且源上较新的数据可能被丢弃;停用应用、关闭使用者和确认恢复目标都需要明确安排。

thin 快照与其他 thin LV 共用池的数据及元数据容量,不拥有单独定额的经典 COW 存储。数据空间满时,依策略可能先排队写入,也可能立即返回错误;元数据耗尽又是另一种失败。问题可以影响多个卷及文件系统,却不等于每个卷瞬间全毁。必须同时监控池的两种百分比、满池行为与可扩容能力,不能只观察某一份快照的虚拟大小。

坏掉的样子

块级快照不会自动成为应用一致的备份。文件系统与数据库缓冲、日志,以及跨卷存放的数据,都需要协调并在还原时正确恢复。复制过程中要检查快照有效性、传播读取错误,之后验证内容与还原结果。命令成功退出或挂载成功都不能证明备份完整;本轮没有进行 LVM 创建、耗尽、扩容或合并实验,也没有用一个内存模型替代这些系统验证。

安排合并前,应识别源与快照双方的打开者,规划应用停机或激活边界。先在一次性卷上演练,并另留独立备份。容量要覆盖整个保留窗口的不同块变化,不能只按其中最忙一小时计算。完成后还需确认实际卷及应用状态,不能仅凭分配计数下降宣布恢复成功。原来的设备名也必须绑定到测试目标,不能直接借用生产卷路径。

经典 LVM 组合未改源块与有限异常存储,并区分耗尽失效、thin 池容量及合并条件。
LVM 保留变化前的 chunk:机制图。

快速验证

以下原命令保持不变并暂缓执行。名称依赖具体环境,也需要已授权的 LVM 访问;其中 lvextend 会改变分配,因此整段不是只读诊断。本轮未执行 device-mapper、内核、逻辑卷或挂载操作,不能把这些命令列在文章里就说验证已完成:

lvs -a -o lv_name,vg_name,lv_attr,origin,data_percent,lv_size
lvs -a -o lv_name,data_percent,metadata_percent vg/thinpool
dmsetup status vg-snap
lvextend -L +2G vg/snap

经典快照的 Data% 与有效状态,不同于 thin 池的 Data% 和 Meta%。dmsetup status 格式取决于目标类型:普通快照分配不必下降,而 snapshot-merge 可向仅剩元数据的状态递减。最后一行既不证明 VG 有空闲容量,也不能使无效快照复活。完整实验需要绑定目标并逐步验证状态变化,相关可执行修改单独保留为暂缓提案。

来源

  • lvcreate(8),说明 -s/--snapshot、COW 与 thin 快照的区别以及容量命令示例,已核验 2026-09-16。
  • lvs(8),定义 lv_attr 状态位,含无效快照,已核验 2026-09-16。
  • Device-mapper snapshot 支持,异常存储、失效语义与 lvconvert --merge 行为,已核验 2026-09-16。
  • lvmthin(7),thin 快照、池耗尽与自动扩容,已核验 2026-09-16。
  • lvconvert(8),立即与延后合并以及卷打开状态条件,已核验 2026-10-18。
  • PostgreSQL filesystem backup,一致快照范围、WAL 与多卷恢复要求,已核验 2026-10-18。