LFCS 88 🐧 LVM — Snapshots - KandZ

⏱️ Estimated read: 13 min | |

An LVM snapshot is a point-in-time view of a Logical Volume. It is not a copy; it is a mapping that records the original state of the blocks that have changed since the snapshot was taken. When the origin is written to, the old data is preserved in the snapshot’s exception store, and the snapshot continues to present the origin as it existed at the moment of creation . This is the mechanism that allows a consistent backup of a live filesystem, and the mechanism that allows a failed upgrade to be rolled back.

This chapter covers the snapshot workflow for the classic (thick) LVM snapshot, which is the form the LFCS exam tests. It begins with the copy-on-write mechanism and the snapshot size calculation, then explains creation, monitoring, and the invalidation that occurs when the exception store fills. The final sections cover merging a snapshot back into the origin with lvconvert --merge, the thin-provisioned alternative, and the constraints that make snapshots a backup aid rather than a backup replacement.

Key point: A snapshot is not a backup. It is a temporary rollback point that lives on the same disks as the origin. If the disk fails, both the origin and the snapshot are lost. The snapshot is for consistency and rollback, not for disaster recovery.

Why snapshots exist

The consistent backup problem. A live filesystem is changing while the backup runs. A file copied at the start of the backup may be inconsistent with a file copied at the end, because the application wrote to both in between. A snapshot freezes the view: the backup reads from the snapshot, which presents the filesystem as it existed at the moment the snapshot was taken, while the origin continues to accept writes . The backup is consistent because the snapshot does not change.

The rollback problem. An upgrade or configuration change can break a system. A snapshot taken before the change allows the system to be restored to the pre-change state with lvconvert --merge. The merge replaces the origin’s content with the snapshot’s content, and the origin returns to the state it was in when the snapshot was created .

The size calculation problem. A snapshot does not need to be the size of the origin. It needs to be large enough to hold the blocks that change while the snapshot exists. A snapshot of a mostly-read-only volume like /usr needs only a few percent of the origin’s size. A snapshot of a write-heavy volume like /home needs much more . The lvs Data% column shows how much of the snapshot’s space has been consumed, and the snapshot becomes invalid when it reaches 100% .

The failure mode difference. Classic snapshots and thin snapshots fail differently. A full classic snapshot becomes invalid, but the origin continues to operate normally. A full thin pool freezes all thin volumes in the pool, which can hang the system . For nightly backups of a production volume, the classic snapshot’s isolated failure mode is often the safer choice .

a. Creating and monitoring a snapshot

The lvcreate command with -s (or --snapshot) creates a snapshot. The -L option sets the snapshot’s size, -n sets its name, and the origin’s path is the last argument.

# Create a 100M snapshot of the origin LV.
sudo lvcreate -s -L 100M -n snap_app /dev/vg_data/lv_app

# Verify the snapshot.
sudo lvs -a -o +devices
# Output shows: snap_app vg_data swi-a-s-- 100.00m lv_app 0.00

The Attr column’s first character is s for a snapshot, and the Origin column shows the source LV. The Data% column is the percentage of the snapshot’s space consumed. A value of 0.00 means no writes have occurred on the origin since the snapshot was taken .

The snapshot is a block device and can be mounted like any other LV. It is writable, but writes to the snapshot do not affect the origin. For a backup, the snapshot is typically mounted read-only.

# Mount the snapshot read-only for a backup.
sudo mkdir -p /mnt/snap
sudo mount -o ro /dev/vg_data/snap_app /mnt/snap

# Run the backup from /mnt/snap.
sudo tar -czf /backup/app.tar.gz -C /mnt/snap .

# Unmount and remove the snapshot when done.
sudo umount /mnt/snap
sudo lvremove /dev/vg_data/snap_app

The snapshot’s space is consumed by writes to the origin, not writes to the snapshot. A snapshot of a quiescent volume can sit at 0.00% indefinitely. A snapshot of an active database can fill in minutes .

b. Invalidation and automatic extension

A classic snapshot becomes invalid when its exception store reaches 100%. The kernel stops tracking changes, the snapshot’s data is no longer consistent, and it cannot be repaired, extended, or recovered. The only option is to remove it and create a new one . The lvs Attr column marks an invalid snapshot with I in the fifth position, and the lv_snapshot_invalid reporting field confirms it .

# Check snapshot usage.
sudo lvs -o lv_name,lv_size,data_percent,lv_snapshot_invalid vg_data

# If the snapshot is invalid, remove it.
sudo lvremove /dev/vg_data/snap_app

The automatic extension is configured in /etc/lvm/lvm.conf. The snapshot_autoextend_threshold setting (minimum 50) triggers the extension when the usage exceeds the threshold, and snapshot_autoextend_percent sets the percentage of the current size to add. The default threshold is 100, which disables automatic extension .

# /etc/lvm/lvm.conf
snapshot_autoextend_threshold = 70
snapshot_autoextend_percent = 20

With these settings, a 1G snapshot is extended to 1.2G when its usage exceeds 700M. The automatic extension requires free space in the VG, and it stops once the snapshot has grown large enough to cover the origin .

Manual extension uses lvextend:

# Extend the snapshot by 100M.
sudo lvextend -L +100M /dev/vg_data/snap_app

c. Merging a snapshot back into the origin

The lvconvert --merge command (or -M) merges a snapshot into its origin. The origin’s content is replaced with the snapshot’s content, and the snapshot is removed. This is the rollback operation: the system returns to the state it was in when the snapshot was created .

# Merge the snapshot into the origin.
sudo lvconvert --merge /dev/vg_data/snap_app

The merge has a constraint: neither the origin nor the snapshot can be mounted when the merge starts, unless the --onactivate option is used. For a root filesystem that cannot be unmounted, the --onactivate flag marks the snapshot for merge on the next activation, and a reboot performs the merge .

# Mark the snapshot for merge on next activation.
sudo lvconvert --merge --onactivate /dev/vg_data/snap_root

# Reboot. The merge occurs during boot.
sudo reboot

The merge is asynchronous. lvconvert starts the merge and returns; the actual work happens in the background. If the system crashes during the merge, the merge resumes on the next activation . While the merge is active, accesses to the origin are directed to the snapshot being merged. When the merge finishes, the origin is reloaded with the merged content and the snapshot is dropped .

The resulting LV has the origin’s name, minor number, and UUID. The snapshot’s identity is not preserved; it is consumed by the merge .

Complete Example Session

# ============================================
# PART 1: THE SNAPSHOT SIZE
# ============================================
# Estimate the size from the write rate.
# A mostly-read-only volume needs 3-5% of the origin.
# A write-heavy volume needs much more.

sudo lvs /dev/vg_data/lv_app

# ============================================
# PART 2: CREATE THE SNAPSHOT
# ============================================
# -s creates a snapshot, -L sets the size, -n sets the name.

sudo lvcreate -s -L 500M -n snap_app /dev/vg_data/lv_app

# ============================================
# PART 3: VERIFY
# ============================================
# The snapshot appears with the origin in the lvs output.

sudo lvs -a -o +devices

# ============================================
# PART 4: MOUNT AND BACKUP
# ============================================
# The snapshot is mounted read-only for the backup.

sudo mkdir -p /mnt/snap
sudo mount -o ro /dev/vg_data/snap_app /mnt/snap
sudo tar -czf /backup/app.tar.gz -C /mnt/snap .

# ============================================
# PART 5: MONITOR USAGE
# ============================================
# Data% shows the consumed space.
# 100% means the snapshot is invalid.

sudo lvs -o lv_name,data_percent /dev/vg_data/snap_app

# ============================================
# PART 6: EXTEND IF NEEDED
# ============================================
# Manual extension before it reaches 100%.

sudo lvextend -L +200M /dev/vg_data/snap_app

# ============================================
# PART 7: REMOVE AFTER BACKUP
# ============================================
# The snapshot is temporary.

sudo umount /mnt/snap
sudo lvremove /dev/vg_data/snap_app

# ============================================
# PART 8: THE ROLLBACK MERGE
# ============================================
# Take a snapshot before an upgrade.
# If the upgrade fails, merge it back.

# Before upgrade:
sudo lvcreate -s -L 1G -n snap_before_upgrade /dev/vg_data/lv_app

# After failed upgrade:
sudo umount /dev/vg_data/lv_app
sudo lvconvert --merge /dev/vg_data/snap_before_upgrade

# ============================================
# PART 9: THE ROOT MERGE
# ============================================
# For root, use --onactivate and reboot.

sudo lvcreate -s -L 2G -n snap_root /dev/vg_root/lv_root
# After a failed change:
sudo lvconvert --merge --onactivate /dev/vg_root/snap_root
sudo reboot

# ============================================
# PART 10: THE FULL PICTURE
# ============================================
# Snapshot: point-in-time view, CoW exception store.
# Size: depends on write rate, not origin size.
# Invalid: 100% full, cannot be repaired.
# Merge: rollback, origin content replaced.

echo "Snapshot workflow complete."

The ten parts walk through creation, verification, backup, monitoring, extension, removal, and the merge rollback. The pattern is consistent: create the snapshot, use it for the backup or the rollback, and remove it when done.

Quick Reference

Snapshot Commands

Command	Effect
`lvcreate -s -L SIZE -n NAME /dev/vg/origin`	Create a snapshot
`lvs -o +devices`	Show snapshots and origin
`lvs -o data_percent`	Show consumed space
`lvextend -L +SIZE /dev/vg/snap`	Extend the snapshot
`lvconvert --merge /dev/vg/snap`	Merge back into origin
`lvconvert --merge --onactivate /dev/vg/snap`	Merge on next boot
`lvremove /dev/vg/snap`	Remove the snapshot

Snapshot Size

Origin Workload	Snapshot Size
Mostly read-only (`/usr`)	3–5% of origin
Moderate writes (`/home`)	10–20% of origin
Write-heavy (database)	50–100% of origin

Automatic Extension (lvm.conf)

Setting	Default	Effect
`snapshot_autoextend_threshold`	100 (disabled)	Extend when usage exceeds
`snapshot_autoextend_percent`	20	Add this percent of current size

Merge Constraints

Constraint	Effect
Origin mounted	Merge fails without `--onactivate`
Snapshot mounted	Merge fails
`--onactivate`	Merge on next activation/reboot
System crash during merge	Merge resumes on next activation

Best Practices

✅ Do This:

# Size the snapshot from the expected write rate.
sudo lvcreate -s -L 500M -n snap_app /dev/vg_data/lv_app              // ✅

# Mount the snapshot read-only for backups.
sudo mount -o ro /dev/vg_data/snap_app /mnt/snap                       // ✅

# Monitor Data% and extend before 100%.
sudo lvs -o lv_name,data_percent /dev/vg_data/snap_app                 // ✅

# Remove the snapshot when the backup is done.
sudo umount /mnt/snap && sudo lvremove /dev/vg_data/snap_app           // ✅

# Use --onactivate for root filesystem rollbacks.
sudo lvconvert --merge --onactivate /dev/vg_root/snap_root             // ✅

❌ Don’t Do This:

# Don't treat a snapshot as a backup.
# The snapshot lives on the same disks as the origin.                 // ❌

# Don't let a snapshot reach 100%.
# An invalid snapshot cannot be repaired.                             // ❌

# Don't merge a mounted origin without --onactivate.
sudo lvconvert --merge /dev/vg_data/snap_app  # fails if mounted       // ❌

# Don't create a snapshot without checking VG free space.
sudo lvcreate -s -L 10G ...  # fails if VFree is insufficient        // ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
Snapshot invalid at 100%	Exception store full	Extend before 100%, or recreate
Snapshot too small	Write rate underestimated	Size from workload, monitor
Merge fails	Origin or snapshot mounted	Unmount, or use `--onactivate`
Snapshot not in `lvs`	No `-a` flag	`lvs -a` shows all
Disk failure loses both	Snapshot on same disks as origin	Snapshot is not a backup

Real-World Examples

1. Create Snapshot

sudo lvcreate -s -L 100M -n snap /dev/vg_data/lv_app

2. List Snapshots

sudo lvs -a -o +devices

3. Check Usage

sudo lvs -o lv_name,data_percent vg_data

4. Extend Snapshot

sudo lvextend -L +100M /dev/vg_data/snap

5. Mount Read-Only

sudo mount -o ro /dev/vg_data/snap /mnt/snap

6. Merge Rollback

sudo lvconvert --merge /dev/vg_data/snap

7. Merge on Boot

sudo lvconvert --merge --onactivate /dev/vg_root/snap_root

8. Remove Snapshot

sudo lvremove /dev/vg_data/snap

9. Check Invalid

sudo lvs -o lv_name,lv_snapshot_invalid

10. Autoextend Config

# /etc/lvm/lvm.conf
snapshot_autoextend_threshold = 70

Visual

The Copy-on-Write Mechanism

┌─────────────────────────────────────────────────────────┐
│  ORIGIN LV: lv_app                                      │
│  ┌───────────────────────────────────────────────────┐  │
│  │  Block A: "old"    ← snapshot taken here           │  │
│  │  Block B: "old"                                    │  │
│  │  Block C: "old"                                    │  │
│  └───────────────────────────────────────────────────┘  │
│                                                         │
│  SNAPSHOT: snap_app                                     │
│  ┌───────────────────────────────────────────────────┐  │
│  │  (empty exception store)                          │  │
│  └───────────────────────────────────────────────────┘  │
│                                                         │
│  ─────────────────────────────────────────────────────  │
│                                                         │
│  AFTER WRITING "new" TO BLOCK A:                        │
│                                                         │
│  ORIGIN: Block A = "new"                                │
│  SNAPSHOT: exception store = { A: "old" }               │
│                                                         │
│  Snapshot view: A = "old", B = "old", C = "old"        │
│  Origin view:   A = "new", B = "old", C = "old"        │
└─────────────────────────────────────────────────────────┘

The Snapshot Lifecycle

┌─────────────────────────────────────────────────────────┐
│  lvcreate -s -L 100M -n snap /dev/vg/lv                 │
│         │                                               │
│         ▼                                               │
│  Snapshot created, Data% = 0.00                         │
│         │                                               │
│         ▼  origin writes                                │
│  Data% grows                                            │
│         │                                               │
│    ┌────┴────┐                                          │
│    ▼         ▼                                          │
│  < 100%    = 100%                                       │
│    │         │                                          │
│    ▼         ▼                                          │
│  Valid    INVALID                                       │
│    │      (cannot repair)                               │
│    ▼                                                    │
│  lvremove or lvconvert --merge                          │
└─────────────────────────────────────────────────────────┘

The Merge Rollback

┌─────────────────────────────────────────────────────────┐
│  BEFORE UPGRADE                                         │
│  lvcreate -s -L 1G -n snap_before /dev/vg/lv_app        │
│         │                                               │
│         ▼                                               │
│  UPGRADE (may modify lv_app)                            │
│         │                                               │
│         ▼  upgrade fails                                │
│  lvconvert --merge /dev/vg/snap_before                  │
│         │                                               │
│         ▼  origin content replaced with snapshot        │
│  lv_app returns to pre-upgrade state                    │
│  snap_before is removed                                 │
└─────────────────────────────────────────────────────────┘

Classic vs Thin Snapshots

┌─────────────────────────────────────────────────────────┐
│  CLASSIC (thick)                                        │
│  - Fixed exception store (-L size)                      │
│  - Invalid at 100%                                      │
│  - Origin continues if snapshot invalid                 │
│  - Low performance with multiple snapshots              │
│                                                         │
│  THIN                                                   │
│  - No fixed size, allocates from pool                   │
│  - Pool exhaustion freezes all thin LVs                 │
│  - Better performance, higher snapshot limit            │
│  - No merge needed to restore (swap volumes)            │
└─────────────────────────────────────────────────────────┘

Summary

Item	Value
Create	`lvcreate -s -L SIZE -n NAME /dev/vg/origin`
Mechanism	Copy-on-write exception store
Size	From write rate, not origin size
Invalid	At 100% Data%, cannot be repaired
Monitor	`lvs -o data_percent`
Extend	`lvextend -L +SIZE /dev/vg/snap`
Merge	`lvconvert --merge /dev/vg/snap`
Root merge	`--onactivate` + reboot
Remove	`lvremove /dev/vg/snap`
Backup	Snapshot is not a backup

Key takeaways:

A snapshot is a point-in-time view, not a copy. The origin’s changed blocks are preserved in the snapshot’s exception store, and the snapshot presents the origin as it existed at creation .
The snapshot size depends on the write rate, not the origin size. A mostly-read-only volume needs a few percent; a write-heavy volume needs much more .
A full snapshot is invalid, not extended. The Data% reaches 100%, the kernel stops tracking, and the snapshot cannot be repaired. Monitoring and extension (automatic or manual) are mandatory .
The merge is the rollback operation. lvconvert --merge replaces the origin’s content with the snapshot’s content and removes the snapshot. For a mounted origin, --onactivate defers the merge to the next boot .
Classic and thin snapshots fail differently. A full classic snapshot is isolated; a full thin pool freezes all thin volumes in the pool .
A snapshot is not a backup. It lives on the same disks as the origin. If the disk fails, both are lost. The snapshot is for consistency and rollback, not disaster recovery .

Remember: An LVM snapshot is a temporary rollback point and a consistency tool. It freezes the view of a live filesystem so that a backup can read a stable state, and it provides a way to undo a failed change. The size must be estimated from the write rate, the usage must be monitored, and the snapshot must be removed when it is no longer needed. The merge is the rollback, and the --onactivate flag is the tool for the root filesystem that cannot be unmounted. But the snapshot is not a backup, and the disk that holds the origin also holds the snapshot.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!