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.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
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.
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.
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
Pick the snapshot technology that matches the underlying storage (LVM under
ext4/xfs; native Btrfs/ZFS where present).
Quiesce the application if a fully consistent image is needed (e.g. FLUSH TABLES WITH READ LOCK for MySQL) before taking the snapshot.
Take the snapshot, then back up from it (tar/rsync) or replicate it
(send/receive) to get the data offsite.
Release/delete the snapshot when done — never leave LVM snapshots around.
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 lvsData% — 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.
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
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 snapshotsudo lvcreate -L 5G -s -n web-snap /dev/data/web
# Mount read-only and back up FROM the snapshot (stable, consistent view)sudomkdir -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 aroundsudo 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.
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 snapshotssudo 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 -psudo 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/hostsudo zfs send tank/data@2026-06-15 | ssh backup@offsite 'zfs recv backup/data'# Incremental between two snapshots with -isudo 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.]
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.
