linux-filesystem-snapshots

name	linux-filesystem-snapshots
description	Use when creating, monitoring, replicating, mounting, or rolling back LVM, Btrfs, or ZFS snapshots on Debian/Ubuntu or RHEL-family hosts. Covers consistency, COW, and rollback; use linux-rsync-sync or linux-archive-integrity for independent backups.
license	MIT
metadata	{"portable":true,"compatible_with":["claude-code","codex"],"author":"Peter Bamuhigire","author_url":"techguypeter.com","author_contact":"[phone]"}

Filesystem Snapshots (LVM / ZFS / Btrfs)

Distro support

LVM snapshots are identical on both families (block-level COW under any filesystem). Btrfs is the Fedora default and present on Debian/Ubuntu; ZFS is out-of-tree on Linux and needs DKMS packages from different repos per family. Body uses Debian/Ubuntu where it differs; the RHEL family (Fedora, RHEL, CentOS Stream, Rocky, Alma, Oracle) column gives equivalents.

Concept	Debian/Ubuntu	RHEL family
LVM tools	apt install lvm2	dnf install lvm2
LVM snapshot (lvcreate -s)	identical	identical
Btrfs tools	apt install btrfs-progs	preinstalled on Fedora (default FS); dnf install btrfs-progs elsewhere
Btrfs default root	optional	Fedora Workstation default; RHEL ships XFS root
ZFS install	apt install zfsutils-linux	dnf install zfs (OpenZFS repo + DKMS; not in base RHEL)
ZFS in base distro	universe (Ubuntu)	not shipped (CDDL/GPL licence conflict)
Default root FS otherwise	usually ext4	usually xfs (no native snapshots → use LVM)

RHEL-family gotcha: the default root is usually XFS, which has no native snapshots — on an XFS or ext4 root you must use LVM snapshots underneath. Btrfs ships natively only on Fedora; ZFS is never in base RHEL/CentOS (licence conflict) and must come from the OpenZFS DKMS repo. LVM is therefore the portable, always-available snapshot layer on the RHEL family.

In sk-* scripts use the common.sh package primitives rather than hardcoding apt/dnf. See ../../10-automation-and-scripting/linux-bash-scripting/SKILL.md and ../../docs/multi-distro/plan.md.

Use When

• You need a crash-consistent point-in-time image of a busy volume (e.g. a live database) so you can back it up without stopping the service.
• You want instant rollback before a risky upgrade or migration.
• You want to ship an efficient block/filesystem-level delta to another host (zfs send, btrfs send).

Do Not Use When

• You need an offsite backup — a snapshot lives on the same pool/VG as production and dies with it. Pair snapshots with ../linux-rsync-sync/SKILL.md or ../linux-archive-integrity/SKILL.md to get the data off the host.
• You are restoring an existing backup in an incident; use ../../09-troubleshooting-and-recovery/linux-disaster-recovery/SKILL.md.
• Day-to-day LVM volume/VG/fstab management; that lives in ../../06-storage-and-filesystems/linux-disk-storage/SKILL.md.

Required Inputs

Artefact	Required?	Source	If absent
Exact LV/subvolume/dataset, technology, mount relation, and objective	yes	Storage inventory and owner	Stop; do not infer a target.
Consistency/quiesce procedure and allowed pause	stateful workload	Application owner	Create only a crash-consistent plan and label its limits.
COW/free capacity, retention, replication target, and rollback approval	yes	Storage metrics and recovery plan	Do not create or roll back.

• The volume/subvolume/dataset to snapshot and its filesystem type.
• Whether the snapshot is for backup capture, rollback, or replication.
• For LVM: enough free space in the VG for the COW area.

Capability Contract

Topology and capacity inspection are read-only. Snapshot creation/deletion, application quiesce, send/receive, mount, and rollback require explicit storage authority. Rollback is destructive and requires separate confirmation naming the exact target and discarded interval.

Degraded Mode

Without storage access, provide technology-qualified commands only. Without application quiesce evidence, label consistency crash-only. Without COW monitoring or a replication target, do not call the snapshot a backup.

Decision Rules

Choice	Action	Failure or risk avoided
Snapshot purpose	Use snapshot for stable capture/short rollback; replicate or back it up off-host for recovery.	Shared-failure-domain loss.
Consistency	Quiesce stateful applications or use their native snapshot hook.	Transactionally inconsistent image.
LVM COW size	Size from expected changed blocks and monitor Data%; abort before exhaustion.	Silent snapshot invalidation.
Rollback	Require named target, backup of later data, and explicit discard approval.	Rolling back the wrong dataset.

Workflow

1. Pick the snapshot technology that matches the underlying storage (LVM under ext4/xfs; native Btrfs/ZFS where present).

2. Quiesce the application if a fully consistent image is needed (e.g. FLUSH TABLES WITH READ LOCK for MySQL) before taking the snapshot.

3. Take the snapshot, then back up from it (tar/rsync) or replicate it (send/receive) to get the data offsite.

4. Release/delete the snapshot when done — never leave LVM snapshots around.

5. Stop on quiesce failure, target ambiguity, or unsafe COW growth; recover by resuming the application, removing the incomplete snapshot when safe, and verifying the source workload before retry.

Quality Standards

• Treat a snapshot as a consistency tool, not a backup. Always copy off-host.
• Size LVM COW space generously and monitor lvs Data% — a full COW snapshot is silently invalidated.
• Quiesce or use --single-transaction dumps for databases; a raw snapshot of a busy DB can still be mid-transaction.

Anti-Patterns

• Calling a local snapshot a backup. Fix: copy or send it to a separate failure domain.

• Snapshotting a busy database blindly. Fix: use the approved quiesce/native backup hook.

• Ignoring LVM COW growth. Fix: size from change rate and monitor Data%.

• Rolling back an ambiguous target. Fix: name the dataset and obtain explicit discarded-interval approval.

• Leaving temporary snapshots indefinitely. Fix: verify export then delete and confirm reclaimed capacity.

• Calling a snapshot "the backup" — it shares the failure domain of production.

• Leaving long-lived LVM snapshots (every write doubles into the COW area; performance degrades and the snapshot can fill and drop).

• zfs rollback/btrfs rollback on the wrong dataset — rollback is destructive and discards everything after the snapshot.

• Snapshotting a busy database without a consistency method. Correction: quiesce or use the database's backup protocol.

• Omitting COW monitoring. Correction: poll capacity and abort/copy before invalidation.

• Keeping only local snapshots. Correction: replicate or export into a separate failure domain.

Outputs

Artefact	Consumer	Acceptance condition
Snapshot record	Storage operator	Names exact source, snapshot, timestamp, consistency mode, capacity, and retention.
Replication/backup evidence	Recovery owner	Off-host target and integrity check are recorded, or shared-domain limitation is explicit.
Cleanup/rollback report	Service owner	Snapshot is removed after capture, or authorised rollback and post-checks are documented.

Evidence Produced

Artefact	Acceptance
Snapshot evidence	Contains topology/capacity, quiesce proof, listing, mount/read, replication/integrity, and cleanup or rollback.

Capture topology, free/COW space, quiesce evidence, snapshot listing, mount/read test, replication status, integrity result, and final cleanup or rollback checks.

Worked Example

For an LVM-backed database, invoke the approved quiesce hook, create a monitored short-lived snapshot, resume writes, back up from the read-only mount, verify the copy, then remove the snapshot before COW pressure grows.

• The snapshot created (LV/subvolume/dataset name) and how it was made.
• How the data was moved offsite (tar/rsync/send) or that rollback was used.
• Confirmation the snapshot was released and free space reclaimed.

References

• references/lvm-snapshots.md
• references/zfs-btrfs-snapshots.md

This skill is self-contained. Every command below is stock lvm2 / btrfs / zfs (the body shows Debian/Ubuntu where it differs; see Distro support above for RHEL-family install). The sk-lvm-snapshot script in the Optional fast path section is a convenience wrapper — never required.

Snapshots vs File Backup — When To Use Which

Goal	Reach for
Crash-consistent image of a live volume	snapshot (this skill), then back up from it
Instant rollback before a risky change	snapshot + rollback (ZFS/Btrfs) or remount the LVM origin
Get data offsite	file backup (rsync / tar) — a snapshot alone is not offsite
Efficient block-level replication to another host	zfs send / btrfs send
Portable archive across hosts/filesystems	tar (linux-archive-integrity)

A snapshot captures an instant on the same storage. If the disk, array, or host dies, the snapshot dies with it. The correct pattern is: snapshot → back up from the snapshot → ship offsite → release the snapshot.

Conceptual trade-offs (Johnson, Fedora Linux Essentials): LVM snapshots are block-level COW with overhead proportional to write activity; Btrfs and ZFS provide near-instant, low-overhead filesystem-level snapshots with checksumming; ZFS scales furthest but uses more memory.

---

LVM Snapshots (works under any filesystem)

A snapshot is a COW copy of an LV capturing its state at an instant — the standard way to back up a live database volume without stopping it.

# 5 GB COW scratch is usually enough for a short-lived snapshot
sudo lvcreate -L 5G -s -n web-snap /dev/data/web

# Mount read-only and back up FROM the snapshot (stable, consistent view)
sudo mkdir -p /mnt/snap
sudo mount -o ro /dev/data/web-snap /mnt/snap
sudo tar --acls --xattrs -czf /backups/web-$(date +%F).tar.gz -C /mnt/snap .
sudo umount /mnt/snap

# Delete when done — NEVER leave LVM snapshots lying around
sudo lvremove -f /dev/data/web-snap

Rules of thumb:

• Size the COW area to at least 10–20% of the origin LV — more if writes are heavy during the backup window.
• A full snapshot is silently invalidated. Monitor lvs — the Data% column shows COW fill; at 100% LVM drops the snapshot.
• LVM snapshots are for short-lived backup windows, not long-term storage.

Full LVM snapshot detail (and a note that day-to-day LVM volume management lives in linux-disk-storage): references/lvm-snapshots.md.

---

Btrfs Snapshots (Fedora default FS)

Snapshots and subvolumes are first-class in Btrfs — near-instant, low space overhead, with data/metadata checksumming.

# Read-only snapshot of a subvolume (read-only is required for send)
sudo btrfs subvolume snapshot -r /data /data/.snapshots/data-$(date +%F)

# List subvolumes and snapshots
sudo btrfs subvolume list /

# Roll back: swap the live subvolume for a snapshot (delete/rename + remount).
# Destructive — discards changes since the snapshot.
sudo btrfs subvolume delete /data
sudo btrfs subvolume snapshot /data/.snapshots/data-2026-06-15 /data

# Replicate to another host/disk (efficient block-level delta)
sudo btrfs send /data/.snapshots/data-2026-06-15 | \
     ssh backup@offsite 'btrfs receive /mnt/backup/'
# Incremental: send only the delta against a parent snapshot with -p
sudo btrfs send -p /data/.snapshots/data-2026-06-14 \
     /data/.snapshots/data-2026-06-15 | ssh backup@offsite 'btrfs receive /mnt/backup/'

[GROUNDING-GAP: btrfs send|receive (incremental -p/-c parents, read-only snapshot requirement, and rollback-by-subvolume-swap) is from upstream btrfs-progs man pages; the Fedora Essentials source covers Btrfs only conceptually. Deepen with UNIX & Linux System Administration Handbook.]

---

ZFS Snapshots (out-of-tree on Linux)

ZFS integrates filesystem and volume management with transactional COW, checksumming, and efficient snapshots/clones.

# Snapshot a dataset (instant, space-efficient)
sudo zfs snapshot tank/data@2026-06-15

# List snapshots
zfs list -t snapshot

# Roll back the dataset to the snapshot (destructive — discards later changes)
sudo zfs rollback tank/data@2026-06-15

# Replicate to another pool/host
sudo zfs send tank/data@2026-06-15 | ssh backup@offsite 'zfs recv backup/data'
# Incremental between two snapshots with -i
sudo zfs send -i tank/data@2026-06-14 tank/data@2026-06-15 | \
     ssh backup@offsite 'zfs recv backup/data'

[GROUNDING-GAP: zfs send|recv (incremental -i/-I, resumable -s receive, rollback semantics, and the OpenZFS-on-Linux licensing/DKMS situation) is from upstream OpenZFS docs; the Fedora Essentials source covers ZFS only conceptually. Deepen with UNIX & Linux System Administration Handbook.]

Full ZFS/Btrfs send-receive workflows: references/zfs-btrfs-snapshots.md.

---

Optional fast path (when sk-* scripts are installed)

Running sudo install-skills-bin linux-filesystem-snapshots installs:

Task	Fast-path script
Create an LVM snapshot, mount it read-only, back it up, then release it	sudo sk-lvm-snapshot --lv /dev/data/web --out /backups/web.tar.gz

This is an optional wrapper around the lvcreate -s workflow above.

Scripts

This skill installs the following scripts to /usr/local/bin/. To install:

sudo install-skills-bin linux-filesystem-snapshots

Script	Source	Core?	Purpose
sk-lvm-snapshot	scripts/sk-lvm-snapshot.sh	no	Take a sized LVM COW snapshot of a given LV, mount it read-only, tar it (--acls --xattrs) to a backup path, then unmount and lvremove the snapshot. Checks VG free space first and warns if the COW size is under 10% of the origin. Asks before creating/removing.