Snapshot · XB Field Notes

LVM snapshots capture a block device in time

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

An LVM snapshot is neither a copy nor a reflink: it is a fixed-size copy-on-write exception store attached to an origin logical volume. lvcreate -s -L 5G -n snap vg/data allocates 5 GiB from the volume group, and the device-mapper snapshot target records the original contents of each origin chunk the first time it is written. Creation is instant whatever the origin’s size, because nothing is copied.

That size is the whole safety margin, and it is the parameter people get wrong. A store sized for a quiet week is exhausted in an hour by a database checkpoint or an rsync, and when it fills the snapshot does not degrade — it becomes invalid and returns I/O errors. The recovery point disappears exactly when you needed it, which is why the store’s free space belongs on a dashboard, not in a runbook.

An exception store, not a copy

A classic LVM snapshot uses two device-mapper targets: the origin is re-mapped as snapshot-origin, and a new snapshot device combines it with a COW device. Reads of unchanged chunks go straight to the origin; the first write to a chunk copies the old chunk into the COW device, then writes the new data. So consumption tracks the number of distinct chunks that changed, not the number of writes: the simulation writes a million times to sixteen hot chunks and consumes fifteen exceptions, about 60 KiB.

Watch it with lvs -a -o lv_name,lv_attr,origin,data_percent,lv_size. A classic snapshot’s lv_attr reads swi-a-s--- — s for snapshot, w writable, and a state character that becomes I when the store is exhausted. data_percent is the store’s fill, and that is the number to alert on, at 70 or 80 percent; 100 percent is not a warning, it is an obituary. lvextend grows the COW device while the snapshot is still valid; lvchange --monitor y lets dmeventd do it automatically.

Exhaustion is invalidation

The kernel documentation is blunt: the COW device will often be smaller than the origin, and if it fills up the snapshot becomes useless and is disabled, returning errors. LVM’s guidance is to plan for expected writes — often 20 percent of the origin — and extend before it fills. A small slice of the store holds the COW block map, so usable data capacity is a little under the -L value.

The blast radius is narrow but the timing is cruel: the origin keeps running normally, so nothing looks wrong until the backup that reads the snapshot fails or the rollback is unavailable. There is no partial mode: at 100 percent, the snapshot never existed.

Merging, and why thin changes the failure

lvconvert --merge vg/snap rolls the snapshot’s changed chunks back into the origin, and it runs in the background while the origin stays usable — writes to chunks not yet merged are deferred. The constraint is on the origin: it must be inactive when the merge is set up, so unmount it, or schedule the merge and activate the origin afterwards. Merging consumes the snapshot, so copy out anything you need first.

Thin snapshots change the failure mode rather than removing it. A thin snapshot is created when the origin is a thin LV and no size is given; it shares blocks in the thin pool instead of owning a store, so its own divergence cannot invalidate it. The pool is the shared resource now: when it runs out, the damage is not one dead snapshot but every thin volume in the pool, which LVM warns may be damaged and hard to repair. thin_pool_autoextend_threshold and dmeventd exist precisely because pool exhaustion is a pool-wide outage.

When it breaks

The classic failure is a backup that silently stops being a backup. The job mounts the snapshot, copies for longer than the store can cover, and the store reaches 100 percent; the snapshot goes invalid and the copy fails — or worse, monitoring watches only the exit code while the job reads a stale mount. Check data_percent on every snapshot LV, alert at 70 percent, and size for the busiest hour in the retention window.

The second failure is the merge that cannot happen when you need it. lvconvert --merge requires the origin closed, and teams discover that during the incident. Rehearse the merge on a disposable volume, keep a real backup independent of the snapshot, and remember that a snapshot whose store is full cannot be merged.

Check it quickly

Look at the store’s fill before trusting the snapshot:

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_percent is the COW store’s fill and should sit well under 100; a state character of I in lv_attr means the snapshot is already invalid. For a thin snapshot, data_percent and metadata_percent on the pool are the numbers that matter; dmsetup status shows allocated sectors against the total so you can watch a merge drain.

Sources

lvcreate(8), documents -s/--snapshot, COW versus thin snapshots and the sizing guidance, 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.

ZFS snapshots give the filesystem a rewind button

Tue, 21 Mar 2028 00:00:00 +0000

A ZFS snapshot is a name attached to a dataset’s block tree at one transaction group. Nothing is copied, nothing is quiesced, and the cost is a few metadata blocks: zfs snapshot tank/data@before-upgrade returns before the shell prompt redraws. Because ZFS never overwrites a live block in place, the old tree stays valid on disk until the last reference to it goes away, and the snapshot is that reference.

That is what makes a nightly wall of history practical, and it is also where this article’s title gets dangerous. Snapshots give you many versions of the data; they do not give you safety from losing the pool. Every snapshot of tank/data lives in tank, so the failure that takes the pool takes the dataset and its history in the same instant. Multiversion and multiversion-safety are different properties, and only replication supplies the second.

A name for one consistent tree

Snapshots are created at a transaction group boundary, so the tree they capture is internally consistent — a database’s files and its metadata freeze at the same instant, not microseconds apart. -r snapshots a dataset and all its descendants, which is what you want for anything holding child datasets; without it, a recursive layout gets snapshots taken at different times at different levels, and incremental replication between them becomes awkward.

Names are the retention policy’s only handle: tank/data@daily-2026-09-16 is prunable by pattern, while an autogenerated name needs bookkeeping. zfs list -t snapshot -o name,used,refer,creation -s creation shows the set with the space each one pins.

Where the space is, in zfs list -o space

ZFS reports space in a column set that answers the only question that matters: whose data is it? zfs list -o space tank/data gives USED, USEDSNAP, USEDDS, USEDREFRESERV, USEDCHILD, REFER and AVAIL. REFER is what the dataset alone needs, USEDSNAP is what its snapshots pin, and USED is the sum. A rising USEDSNAP with a flat REFER means the snapshots, not the data, are eating the pool.

The fixture builds a wall of thirty daily snapshots over a 64 MiB dataset with 2 MiB of churn per day. Creation costs 0 KiB every single time — the cost lands on the write that follows, 2048 KiB for 2 MiB rewritten — and the whole wall costs 60 MiB against 1920 MiB for thirty full copies. That ratio is the entire argument for snapshots, and why nobody notices the pool filling until it is nearly full.

Holds, diff, and comparing versions

A hold is a named reference that makes destruction fail with EBUSY: zfs hold keep tank/data@daily-2026-09-16 protects a snapshot, zfs holds lists the holders, and zfs release keep clears it. Backup software holds the snapshot it is sending so retention cannot delete it; the cost is that pruning then fails until the hold is released, and a stuck hold can pin a snapshot for months.

zfs diff tank/data@daily-2026-09-15 tank/data@daily-2026-09-16 reports per-path changes — + created, - removed, M modified, R renamed — and both snapshots must still exist, which is why diffing against yesterday is easy and against last month may not be. Read a snapshot’s contents through the hidden .zfs/snapshot/<name> directory; there is no separate mount for a snapshot, and snapdir=visible makes it listable.

When it breaks

The failure that matters is the one the title invites: a pool loss. A failed controller, a backplane fault, or pool-wide corruption removes the dataset and every snapshot of it atomically; there is no partial survival. The only defence is a copy outside that pool: zfs send -i tank/data@yesterday tank/data@today | zfs receive backup/data writes an independent, checksummed stream into a second pool, and only that stream survives the first pool’s death. A snapshot wall with no replica is a single point of failure with a nicer interface.

The second failure is silent space creep plus retention that cannot run. USEDSNAP grows while REFER stays flat, the pool passes 80 percent, and ZFS starts refusing writes with no space left even though the datasets look reasonable — slop and reservations are not visible from inside the filesystem. If a snapshot is also held for a clone, destroying it fails, and rolling back past a clone’s origin forces a recursive destroy. Long-lived holds turn retention into a dependency graph, so keep hold lifetimes short and audited.

Check it quickly

See what the snapshots cost and whether they can be removed:

zfs list -t snapshot -o name,used,refer,creation -s creation tank/data
zfs list -o space tank/data
zfs holds tank/data@daily-2026-09-16
zfs diff tank/data@daily-2026-09-15 tank/data@daily-2026-09-16
zfs send -i tank/data@daily-2026-09-15 tank/data@daily-2026-09-16 | zfs receive backup/data

used per snapshot is the space that snapshot alone pins, and a fresh snapshot’s value is near zero; the space columns then show USEDSNAP against REFER, and a rising USEDSNAP with a flat REFER is the signal to prune. If zfs destroy fails with a busy snapshot, zfs holds names the tag to release. The last line is the only one that protects against losing the pool; run it on a schedule.

Sources

zfs-snapshot(8), snapshot creation semantics and recursive snapshots, checked 2026-09-16.
zfs-list(8), the space column set including USEDSNAP, USEDDS and REFER, checked 2026-09-16.
zfs-hold(8), holds, zfs holds, and the EBUSY returned by destroy, checked 2026-09-16.
zfs-send(8), incremental replication streams that leave the pool, checked 2026-09-16.

Btrfs snapshots are copy-on-write, not copies

Sun, 14 Nov 2027 00:00:00 +0000

A btrfs snapshot is not a copy of anything. btrfs subvolume snapshot creates a new subvolume whose root points at the same extent tree as the source, so every extent the two share is referenced twice and stored once. Creation is a metadata operation measured in milliseconds whether the subvolume holds a gigabyte or ten terabytes.

That makes snapshots the cheapest rollback primitive on the box, and it is also why they are the most commonly over-trusted. Space grows with divergence, not with the size of the data; the cost arrives later, on somebody else’s write, on the same device that holds the original. A snapshot you never prune is a slow-motion disk-full incident, and a snapshot on the same disk is not a backup no matter how many of them you keep.

Shared extents, not copied blocks

Snapshots are subvolumes, and a subvolume is a subtree with its own root, so the snapshot machinery is the reference-counting machinery that makes reflinks work. Take a read-only snapshot with btrfs subvolume snapshot -r /data /snap/data-2026-09-16; the -r matters, because a writable snapshot starts diverging the moment anything writes to it, and a backup target should not be writable in the first place.

The first write after a snapshot is what costs. When either side overwrites a shared extent, the filesystem allocates a new extent for the writer and leaves the old one to the other side, so the price of a snapshot is paid by the next write, in units of the extents that write touches — not by the snapshot command. APFS clonefiles share extents under the same rule, and the fixture measures the shape: a 64 MiB clone costs 0 KiB, a plain 64 MiB copy costs 65536 KiB, and overwriting the first 8 MiB of the clone costs 8192 KiB. Rewriting that same 8 MiB a second time costs 0 KiB, because those extents already diverged.

Where the space actually goes

btrfs filesystem du is the honest accounting: it prints Total, Exclusive and Set shared for each argument, where Set shared is the space it shares with the others named on the command line. Right after a snapshot, Exclusive should be near zero and Set shared close to the origin’s Total. compsize gives the same split per file, and btrfs qgroup show -reF tracks exclusive and referenced bytes per qgroup when quotas are enabled.

Deleting the origin does not free the shared extents — they become the snapshot’s exclusive data, and the space changes owner. This is the most common support question about btrfs: a file is deleted and df does not move. Only when the last reference goes away does the space return, which is why retention policy and snapshot cadence must be designed together.

A restore point is not a replica

Snapshots live in the same filesystem on the same device as their source, so a controller failure, a dead disk, or a btrfs check gone wrong takes the data and every snapshot of it in one motion. They defend against exactly one class of accident — the write that should not have happened — and they are excellent at it: rollback is local, instant, and needs no network.

Real protection means an independent copy: btrfs send walks a snapshot and emits a stream that btrfs receive applies to another filesystem, with -p sending only the delta from a parent snapshot. Send that stream to a different machine or a different pool. The distinction: send is the replication mechanism, and the snapshot is just the object it replicates.

When it breaks

The classic failure is the delete that frees nothing: someone removes a 40 GB directory, df is unmoved, and they delete more to compensate. Run btrfs filesystem du -s across the subvolume and its snapshots and look for one whose Exclusive value accounts for the gap. If the snapshots are read-only, the fix is deleting snapshots, not more files.

The second failure is a full filesystem, which on btrfs is worse than on ext4. Metadata needs space of its own, and a copy-on-write filesystem with no free space cannot allocate the extent a write requires, so one at 100 percent can fail writes that would succeed elsewhere and can go read-only. Keep headroom — 5 percent is not paranoia — bound snapshot retention, and remember that a snapshot of a nearly full filesystem also commits you to space for its divergence.

Check it quickly

Confirm the snapshot shares rather than copies, and find what is holding the space:

btrfs subvolume snapshot -r /data /snap/data-$(date +%F)
btrfs filesystem du -s /data /snap/data-2026-09-16
compsize /snap/data-2026-09-16
btrfs filesystem usage /data

du prints a Total, Exclusive and Set shared triple per path: a fresh snapshot’s Exclusive should be a few MiB of metadata at most while Set shared tracks the origin’s Total. If Exclusive already equals Total, the snapshot is a full copy. btrfs filesystem usage then shows how much divergence the device can still absorb.

Sources

btrfs subvolume documentation, subvolume and snapshot semantics including read-only snapshots, checked 2026-09-16.
btrfs filesystem documentation, defines the du Exclusive and Set shared columns used above, checked 2026-09-16.
btrfs qgroup documentation, exclusive and referenced byte accounting per qgroup, checked 2026-09-16.
btrfs send documentation, the replication stream that moves a snapshot off the machine, checked 2026-09-16.