Terminal.Drill Get the app
ch11/l03

Snapshots, rollback, and final evidence

Plan snapshot work around capacity risk and restore path.

lvs -a -o +devices 30 min read, 40 min lab operator

Snapshots are not backups. They depend on available space and can fail or become useless when full. A useful snapshot plan names origin, snapshot, expected change window, capacity monitoring, and restore sequence.

In the field

Before a risky package upgrade, you need a snapshot plan and a rollback packet.

Worked command

$ lvs -a -o +devices$ lvcreate -s -n var-pre-upgrade -L 5G /dev/vg0/var$ lvs -a$ lvconvert --merge /dev/vg0/var-pre-upgrade
Anti-pattern

Do not create snapshots without monitoring free space and documenting restore steps.

Safer pattern

Treat snapshots as one control in a rollback plan, not the whole backup strategy.

Knowledge check

Before a risky upgrade you take an LVM snapshot. Why can a full snapshot make rollback impossible?

  • A A snapshot needs free space for changed blocks; once exhausted it is invalidated and cannot merge back
  • B A full snapshot automatically overwrites the origin LV to reclaim space
  • C Snapshots are full backups, so a full one means the backup is complete and safe
  • D lvconvert --merge refuses to run unless the snapshot is at zero percent usage
Show the answer

Correct: A. A snapshot needs free space for changed blocks; once exhausted it is invalidated and cannot merge back

Why

A snapshot stores only changed blocks in allocated space; if writes exhaust that space it is dropped and lvconvert --merge has nothing valid to restore from. The idea that a snapshot is a complete backup is the trap, snapshots are one rollback control, not the backup.

Practice checklist

  1. Use sample output or a disposable LVM lab.
  2. Identify origin and snapshot names.
  3. Write the restore sequence before any simulated action.

Deliverable evidence

  • Snapshot plan with origin, size, monitoring, and rollback path.
Teaching diagramch11 · mental model
device -> filesystem -> mount, layered through LVM /dev/sda block device (lsblk) PV -> VG -> LV pvs / vgs / lvs ext4 / xfs filesystem (blkid) /var (mount) findmnt / df -h grow: lvextend -r -r resizes the filesystem too lvcreate -s snapshot of origin LV snapshot fills -> rollback lost (not a backup) verify from many signals before any destructive command

shows: How a mount point sits on a filesystem, on an LV stacked through VG and PV onto a block device, plus where growth and snapshots act.

does not prove: It is a schematic of the relationships, not evidence of your host's actual layout — only lsblk, findmnt, blkid, and lvs output prove that.

Memorize this

Commit these to memory, then drill them until recall is automatic.

snapshotoriginlvcreate -slvconvert --mergecapacity risk

Reference

lvs -alsblk -f
Recall practice · Meaning -> command

cue Command to merge a snapshot back into its origin to roll back

show recall target

lvconvert --merge /dev/vg0/<snapshot>

See this drill type Practice recall in the app