LVM snapshots capture a block device in time

Mon, 10 Apr 2028 00:00:00 +0000

A classic LVM snapshot uses a copy-on-write exception store attached to an origin logical volume. lvcreate -s -L 5G -n snap vg/data requests a 5 GiB store, subject to allocation granularity and available volume-group space. It avoids copying the whole origin at creation, but does not guarantee zero work or instant completion. Thin snapshots use a different shared-pool mechanism.

The exception store must cover distinct changed chunks and metadata for the entire retention window, including writes during backup. A burst can consume it earlier than a quiet-workload estimate predicts. If a classic store fills, the snapshot becomes invalid and reads fail. Monitor validity and growth early enough to extend or finish the backup; a nominal percentage alone is not a recovery plan.

An exception store, not a copy

The origin uses the snapshot-origin target, while snapshot combines unchanged origin chunks with preserved exceptions. Writes to the snapshot itself go to its COW device. Repeated changes to an already-excepted chunk do not require another original copy for that snapshot. The earlier million-write, sixteen-chunk, fifteen-exception result has no recovered trace; touching all sixteen distinct chunks would require sixteen data exceptions, plus metadata.

lvs -a -o lv_name,lv_attr,origin,data_percent,lv_size exposes type, state and usage. swi-a-s--- is illustrative, not one universal attribute string; the fifth character I means invalid snapshot. Alert thresholds must leave room for observed write rates and response time. lvextend needs available VG extents. lvchange --monitor y enables monitoring, not guaranteed extension: dmeventd, configured autoextend policy and free capacity are also required.

Exhaustion is invalidation

Kernel documentation says an exhausted classic COW store is disabled and returns errors. The lvcreate manual’s twenty-percent-of-origin command is an example, not a general sizing recommendation. Account for chunk granularity, metadata, workload bursts and the full backup duration. Increasing capacity before exhaustion preserves a valid snapshot; an invalid recovery point must not be treated as complete merely because its LV still exists.

Origin writes normally continue when a classic snapshot overflows, but this does not guarantee that unrelated origin or storage failures cannot occur. An invalid snapshot is unusable as the recovery point; it did exist and may have supplied an earlier verified backup. Do not confuse current snapshot validity with the separate integrity of a copy already completed elsewhere.

Merging, and why thin changes the failure

lvconvert --merge vg/snap merges a persistent COW snapshot back into its origin and consumes the snapshot. It starts immediately when both LVs are closed; otherwise LVM defers it until an activation when both are closed. The origin may serve I/O after merging begins, with affected writes deferred as required. This is not a guarantee of interruption-free rollback, and newer origin data can be discarded.

A thin snapshot shares data and metadata capacity with other thin LVs instead of owning a separately sized COW store. Data exhaustion may queue writes or return errors according to policy; metadata exhaustion is another failure mode. Such failures can affect multiple volumes and filesystems, but do not imply instant destruction of every volume. Monitor both pool percentages, policy and extension capacity.

When it breaks

A block snapshot is not automatically an application-consistent backup. Filesystem and database buffers, logging and data spread across volumes require coordinated handling and recovery. During copying, check snapshot validity and propagate read failures; verify the resulting contents and a restore. A successful command exit or mount alone does not establish completeness, and this review performed no LVM creation, exhaustion, extension or merge experiment.

Before a merge, identify open users of both origin and snapshot and plan the application outage or activation boundary. Rehearse on disposable volumes and keep an independent backup. Size for all distinct changes across the retention window, not just its busiest hour. Confirm the actual resulting volume and restored application state; do not infer success solely from declining allocation counters.

LVM keeps changed chunks — mechanism diagram.

Check it quickly

The unchanged lines below remain held. They contain environment-specific names and require authorized LVM access; lvextend changes allocation, so this is not a read-only diagnostic block. No device-mapper, kernel, volume or mount operation was executed:

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

Classic snapshot Data% and its validity state differ from a thin pool’s Data% and Meta%. dmsetup status output is target-specific: normal snapshot allocation need not fall, while snapshot-merge allocation can decrease toward its metadata remainder. The final line neither proves free VG capacity nor revives an invalid snapshot. A separately held complete exercise must bind targets and verify each claimed transition.

Sources

lvcreate(8), documents -s/--snapshot, COW versus thin snapshots and illustrative sizing commands, checked 2026-09-16.
lvs(8), defines the lv_attr state characters including invalid snapshot, checked 2026-09-16.
Device-mapper snapshot support, the exception store, invalidation and lvconvert --merge behaviour, checked 2026-09-16.
lvmthin(7), thin snapshots, pool exhaustion and automatic extension, checked 2026-09-16.
lvconvert(8), immediate versus deferred merge and open-volume conditions, checked 2026-10-18.
PostgreSQL filesystem backup, consistent snapshot scope, WAL and multi-volume recovery requirements, checked 2026-10-18.