LVM snapshots and rollback - the local safety net · Linux

LVM snapshots are the cheap, instant way to roll back local changes. Use them before a deployment, a database migration, or any other risky operation. This lesson shows the workflow.

When to take a snapshot

Take an LVM snapshot before:

A database migration or schema change.
A deployment to production.
An OS upgrade (if you must do it on a live system).
Any operation that changes a lot of data on the LV.

Configuration changetake snapshot— lvcreate with -s creates a snapshot. The 10G is the initial space reservation - the snapshot grows as the original LV changes. The snapshot name data-pre-deploy is descriptive. Mount it read-only or read-write depending on use case.

$ lvcreate -L 10G -s -n data-pre-deploy /dev/vg_data/data

Logical volume 'data-pre-deploy' successfully created

Verifying the change

Read-only / Safelvdisplay— lvdisplay shows the snapshot details. LV Snapshot status shows that this is a destination for the original LV's data. The snapshot is mounted or unmounted independently of the original - but on XFS it needs mount -o nouuid, because the block-identical copy carries the origin's filesystem UUID and XFS will not mount two filesystems that claim the same one.

$ lvdisplay /dev/vg_data/data-pre-deploy | head -10

--- Logical volume ---
LV Path                /dev/vg_data/data-pre-deploy
LV Name                data-pre-deploy
VG Name                vg_data
LV UUID                xyz...
LV Write Access        read/write
LV Snapshot status     active destination for data
LV Status              available

On XFS the snapshot mount fails until you pass `nouuid`

A snapshot is a block-for-block view of the origin, so it carries the origin’s filesystem UUID. XFS treats a duplicate UUID as a refusal condition:

mount: /mnt/snap: wrong fs type, bad option, bad superblock ...
XFS (dm-3): Filesystem has duplicate UUID <uuid> - can't mount

The origin is mounted — that is the whole point of taking a snapshot — so the collision is guaranteed, not occasional. Mount it with nouuid, and add norecovery to avoid replaying the origin’s log into the copy:

mount -o ro,nouuid,norecovery /dev/vg_data/data-pre-deploy /mnt/snap

ext4 does not enforce the same restriction and needs neither option. This is the single most common reason a backup script that was written and tested on an ext4 host fails on the first RHEL-family server it meets.

Rolling back

Data-loss riskrollback via merge— lvconvert --merge rolls the snapshot back into the original LV. Any changes to the original LV since the snapshot are discarded. The snapshot disappears after the merge. The original LV's data is restored to its state at snapshot creation time.

$ umount /data; lvconvert --merge /dev/vg_data/data-pre-deploy

Cleaning up

Read-only / Safelv_time— lvs -o+lv_time shows the snapshot creation time. Use this to identify old snapshots for cleanup. Snapshots that are weeks old are usually safe to remove - the changes they captured have been validated.

$ lvs -o+lv_time

  LV           VG    Attr       LSize
data         vg0   -wi-ao----  100.00g
snap-old     vg0   swi-aos---  5.00g  2026-01-01 10:00:00