Classic LVM Snapshots: COW Capacity, Backup Consistency, and Controlled Rollback

A classic LVM snapshot preserves a block-level view of an origin logical volume while that origin continues changing. It uses a separate copy-on-write store for chunks whose historical contents must be retained. The snapshot’s apparent size can match the origin even though its allocated change store is much smaller. That makes snapshots useful for short backup windows and controlled rollback, but it also makes them easy to invalidate through underestimated write activity.

This article concerns classic device-mapper COW snapshots of ordinary LVs. Thin-pool snapshots have a different allocation and exhaustion model; Btrfs and ZFS snapshots operate through their own filesystem designs. Confirm the segment type with LVM tools before applying capacity or recovery advice. All modifying examples assume an explicitly named disposable lab VG and LV, not the system’s production root volume.

Follow the block paths before choosing a size

The kernel’s snapshot-origin target protects the old contents when the origin receives a write. A snapshot read can then obtain changed chunks from the COW store and unchanged chunks from the origin. Snapshot writes also consume the COW store. This is why an ordinary writable snapshot can diverge from its original point-in-time contents and why snapshot capacity does not measure filesystem free space.

Estimate the number of distinct chunks changed over the snapshot’s intended lifetime, plus metadata and safety margin. Rewriting the same application file repeatedly does not necessarily consume capacity at the rate implied by total bytes written, while touching a large number of previously unchanged chunks can consume it quickly. Database compaction, filesystem maintenance, package upgrades, and background workloads can change the pattern substantially.

Measure on a representative workload rather than applying a universal percentage. A hypothetical 100 GiB origin with a 10 GiB snapshot store is not guaranteed to survive a 10 GiB application transaction, nor does it imply the snapshot is only 10 GiB of readable data. Record expected lifetime, observed change growth, free VG extents, and the action taken when the reserve is approached.

Inspect the actual LV and volume-group reserve

Start with read-only inventory:

sudo lvs -a -o lv_name,vg_name,segtype,lv_size,origin,data_percent
sudo vgs -o vg_name,vg_size,vg_free
sudo pvs -o pv_name,vg_name,pv_size,pv_free
findmnt

Use lvs -o help if the installed LVM release exposes a different reporting field. Record the origin and its filesystem mountpoint. A free-space report from df does not tell you whether the VG can extend a snapshot. Likewise, free space in one VG cannot automatically support a snapshot in another.

Preserve a verified independent backup before a risky upgrade. A snapshot located on the same storage is not protection against loss of that storage, accidental deletion of both objects, or a compromised administrator. The snapshot provides a local recovery point with a capacity and lifetime limit; the independent backup provides another recovery path.

Coordinate consistency before creation

A block snapshot is not inherently an application-consistent database backup. A database may require a native backup mode, a checkpoint and log strategy, or a clean stop. Multiple volumes also need coordinated capture if a transaction spans them. Write down the application’s documented recovery procedure and test restoring the intended snapshot content before using the method for production backups.

For an application using a single standalone filesystem, one illustrative maintenance sequence is to stop writers normally, verify they stopped, create the snapshot, and restart them. The actual service and volume names are deliberately omitted because they depend on the deployment. Filesystem freeze can be part of an approved procedure, but a failed command must not leave a live filesystem frozen indefinitely; use a rehearsed cleanup path and a console when appropriate.

On a prepared non-thin lab LV, a creation example is:

sudo lvcreate --snapshot --size 4G --name data_before_change labvg/data
sudo lvs -a -o lv_name,segtype,origin,lv_size,data_percent labvg

The 4 GiB store is an illustrative allocation, not a sizing recommendation. Inspect the result and available reserve before resuming the workload. LVM coordinates the underlying device-mapper tables; do not manually replace snapshot-origin tables to imitate this operation. The kernel documentation warns that loading or unloading snapshot targets without the required origin suspension can corrupt data.

Back up the point-in-time view deliberately

Mounting the snapshot depends on the filesystem’s recovery and identity rules. A filesystem snapshot may contain a dirty journal, and some filesystems require special handling when a clone has the same identity as its mounted origin. Do not publish a universal mount -o ro recipe and call it sufficient for every filesystem. Consult the specific filesystem documentation and prefer an application-native backup where its consistency contract requires one.

Use a dedicated snapshot mountpoint or backup tool and keep normal applications away from it. If a backup process writes to the snapshot, its data no longer represents a strictly untouched recovery view and the writes consume change-store capacity. Verify the backup’s destination is independent, its file permissions and metadata are preserved as required, and a sample restore can actually start the application or recover a known data set.

Define a maximum backup duration and a capacity-abort threshold before starting. If the backup is slower than expected, the correct response may be to stop it, release the snapshot, and repeat with a larger planned reserve. Keeping a doomed snapshot indefinitely because the copy is almost finished can turn an apparent backup into unreadable recovery evidence.

Monitor growth and extend before invalidation

Watch the snapshot’s reported usage and the VG’s free extents throughout the window:

sudo lvs -a -o lv_name,origin,lv_size,data_percent labvg
sudo vgs -o vg_name,vg_free labvg

Current upstream reporting defines data_percent for active snapshots and also provides lv_snapshot_invalid as an explicit invalidation indicator. Verify available fields with lvs -o help on the installed release and include that state in monitoring. An empty percentage for an inactive LV is not proof of zero consumption.

If the store approaches the preplanned threshold and reserve remains available, an illustrative extension is:

sudo lvextend --size +2G labvg/data_before_change

Confirm growth in the next report. An alert alone does not extend storage, and an automatic-extension design still depends on monitoring services, policy, available extents, and timely execution. Test those dependencies instead of assuming a configured percentage guarantees recovery.

When the classic COW store fills, the kernel can invalidate the snapshot and return I/O errors through that snapshot. Treat an invalidated snapshot as a failed recovery point, not as a sparse backup with a few missing files. Preserve diagnostics, stop consuming it, and recover from a verified independent backup or recreate a new snapshot after resolving capacity. Extending storage after invalidation is not a general promise to reconstruct the lost historical view.

Treat merge as an explicit rollback operation

Merging a classic snapshot restores its block contents into its origin. This can discard newer origin changes, so obtain an authorized rollback decision and preserve any data that must survive. Stop application writers and close the relevant filesystem consumers as the storage plan requires. On the lab LV, the operation is:

sudo lvconvert --merge labvg/data_before_change
sudo lvs -a -o lv_name,origin,lv_attr,data_percent labvg

The upstream LVM manual explains that a merge can be deferred until activation when the origin or snapshot cannot be closed; root-filesystem rollback commonly requires a reboot or another planned activation boundary. Command success is therefore not proof that rollback has finished. Observe state through LVM, then verify known old data, filesystem health, and application recovery.

If rollback is unnecessary, remove the unused snapshot only after the independent backup and maintenance result have passed their checks. Keep a clear record of creation time, application consistency method, capacity history, backup identity, and whether the snapshot was removed or merged. The useful promise of a classic snapshot is a tested, temporary block recovery point; its value depends on monitoring and recovery evidence throughout its lifetime.

Related:

Sources: