LVM Snapshots & Practical Use Cases

fs1-5's own compare-table flagged LVM snapshots as "COW-based, distinct from Btrfs/ZFS's own." This chapter is that distinction, in full — plus the one real-world use case that makes LVM snapshots worth knowing well: safely backing up data that's actively being written to.

How LVM Snapshots Work — COW at the Block Layer, Not the Filesystem Layer

Btrfs and ZFS snapshots (fs1-3, fs1-4) are implemented inside the filesystem itself, which natively understands blocks being shared between a subvolume/dataset and its snapshots. LVM snapshots are a genuinely different mechanism, working one layer below the filesystem — the filesystem sitting on top has no idea a snapshot even exists.

Creating an LVM snapshot doesn't copy the volume. It creates a new, small logical volume that initially holds nothing, reserved purely to record changes made to the original after the snapshot point. When the original volume is written to, LVM first copies the block's old content into the snapshot volume before letting the write proceed — copy-on-write, but implemented as "move the old data out of the way," not Btrfs's more sophisticated multi-way block sharing. This means an LVM snapshot has to be sized in advance to hold however many changed blocks are expected during its lifetime — a real, practical difference from Btrfs/ZFS's own dynamically-growing snapshots.

Real Commands

-s marks the new logical volume as a snapshot of mylv; -L 5G reserves 5GB purely for the snapshot's own changed-block store — not a full copy of the original volume's size.

Why the Reserved Size Matters — Snapshot Overflow

Because LVM snapshots pre-allocate a fixed amount of space for tracking changed blocks, rather than growing dynamically the way Btrfs/ZFS snapshots effectively do, a snapshot that runs out of reserved space while the original keeps changing simply overflows — becoming invalid and unusable. This is a real, practical gotcha that needs active monitoring, not a one-time sizing decision that can be forgotten.

A Real Use Case — Safe Backups of a Live Database

dbsec1-8 covered backup security — encryption, tested restores, backups as a ransomware target. Here's the mechanical problem LVM snapshots solve underneath all of that: backing up a live, actively-written database file directly risks capturing an inconsistent, mid-write state — a backup that looks complete but is actually corrupted, because different parts of the file were captured at different moments while writes kept happening in between.

An LVM snapshot solves this cleanly. The snapshot itself is taken near-instantaneously, freezing the origin volume's exact state at that moment from the snapshot's own point of view — while the original keeps being written to completely normally, with essentially no downtime. The backup then reads from the frozen, unchanging snapshot at leisure, with a fully consistent view throughout, regardless of how long the backup itself takes or how much the live data changes in the meantime.

The archive this workflow produces is exactly the kind of artifact dbsec1-8's own encryption-at-rest guidance should be applied to before it's stored anywhere long-term — this chapter solves the "how do I capture a consistent snapshot of live data" problem; dbsec1-8 already covers what happens to that snapshot once it's a backup file sitting in storage.

Hands-On Exercises