LVM snapshots: back up online and roll back

An LVM snapshot is an instant picture of a volume at a precise moment, taken online, without stopping the service. It serves two purposes: backing up a volume in use consistently, and rolling back after a risky operation. This guide shows how to create a snapshot, use it for a backup, and above all restore an earlier state with lvconvert --merge. For intermediate Linux administrators, on Debian/Ubuntu and RHEL/AlmaLinux. All outputs come from a real test on AlmaLinux 10 (LVM 2.03.36).

What you will learn

• Create a snapshot of a logical volume with lvcreate -s
• Understand the copy-on-write mechanism and size the snapshot
• Back up a volume online without inconsistency
• Restore an earlier state (rollback) with lvconvert --merge
• Keep a full snapshot from being invalidated

Prerequisites

An LVM stack in place with at least one logical volume formatted and mounted (see the LVM guide). The Volume Group must have free space (vgs, VFree column) to host the snapshot.

What is an LVM snapshot

A snapshot is a frozen image of a logical volume (the origin) at the moment it is created. The mechanism is called copy-on-write (COW): instead of copying the whole volume, LVM only stores the blocks changed since the snapshot was taken. As long as nothing changes on the origin, the snapshot consumes almost nothing.

That is what makes the snapshot fast and light to create, even on a large volume. The size you reserve (-L) only stores these differences: you size it according to the expected volume of writes during the snapshot's lifetime, not according to the size of the origin.

Create a snapshot

You create a snapshot with the -s (--snapshot) option, reserving a size for the changed blocks:

1. Create the snapshot of an lvdata volume, with 256 MiB reserved:

   sudo lvcreate -s -L 256M -n lvdata-snap vg_data/lvdata

     Logical volume "lvdata-snap" created.

2. Change the origin (the volume keeps serving normally), then watch the snapshot fill up:

   sudo lvs -o lv_name,origin,data_percent vg_data

     LV          Origin Data%
     lvdata
     lvdata-snap lvdata 0.02

The lvdata-snap snapshot points to its origin lvdata, and its Data% climbs as the origin is changed. Here, after a small write, it is only 0.02% full: only the blocks actually changed are copied.

Back up a volume online consistently

The first use of a snapshot is the consistent backup. Backing up a volume while it is being written produces inconsistent files (half modified). The snapshot solves this problem: you freeze the state at time T, then back up the snapshot while the origin keeps running.

# 1. Freeze the current state
sudo lvcreate -s -L 1G -n db-snap vg_data/lv_db

# 2. Back up the snapshot (the origin stays in service)
sudo mount -o ro /dev/vg_data/db-snap /mnt/snap
sudo tar czf /backup/db-$(date +%F).tar.gz -C /mnt/snap .
sudo umount /mnt/snap

# 3. Release the snapshot once the backup is done
sudo lvremove -y vg_data/db-snap

The database suffers no interruption: it writes to the origin, you back up the frozen image.

Restore an earlier state with lvconvert --merge

The second use, often forgotten, is the rollback. Before a risky update, you take a snapshot; if the operation goes wrong, you merge the snapshot into the origin to go back to the previous state, with lvconvert --merge.

1. Unmount the origin (an immediate merge requires it to be closed):

   sudo umount /mnt/data

2. Merge the snapshot into the origin:

   sudo lvconvert --merge vg_data/lvdata-snap

     Merging of volume vg_data/lvdata-snap started.
     vg_data/lvdata: Merged: 100.00%
     Merge of snapshot into logical volume vg_data/lvdata has finished.
     Logical volume "lvdata-snap" successfully removed.

3. Mount again: the origin is back to the snapshot's state, and the snapshot is consumed then removed automatically, as the last line of output says:

   sudo mount /dev/vg_data/lvdata /mnt/data
   cat /mnt/data/fichier.txt
   # contenu version 1   (later changes are gone)

If the origin cannot be unmounted

If the origin is still open, lvconvert --merge returns at once with the message "Delaying merge since origin is open": the merge is deferred to the next activation of the volume. For a data partition, a umount followed by lvchange -an then lvchange -ay is enough to trigger it. For a root file system, which cannot be closed, that activation happens at the next reboot.

As long as the merge is not finished, the origin stays tied to the merging snapshot. Meanwhile, LVM refuses to take a new snapshot of the same origin, with the message "Snapshots of an origin that has a merging snapshot are not supported". Wait until lvs no longer lists the snapshot before creating another one.

The danger: a full snapshot

A classic snapshot only has a fixed reserve to store the copied blocks, and that is its weak point. Every write on the origin consumes a little of this reserve: if the origin is changed more than the reserved size, the snapshot fills up to 100%. Here is what lvs shows for a 12 MiB snapshot after 40 MiB of writes on the origin:

  LV    Attr       Data%
  lv    owi-a-s---
  petit swi-I-s--- 100.00

A full snapshot is invalidated

The I in the fifth character of Attr means invalid. The kernel logs it ("Invalidating snapshot: Unable to allocate exception"), and the snapshot no longer mounts: it is useless for a rollback as well as for a backup. The origin, for its part, keeps working. The backup or restore you were counting on is lost with no visible error on the application side.

The dmeventd daemon, which monitors snapshots by default (monitoring=1 in lvm.conf), writes "WARNING: Snapshot … is now 80.00% full" to the system log from 80%, then at every 5% step. When the snapshot becomes invalid, it also tries to unmount it. These messages are the last signal before the loss: watch them, or watch the Data% directly.

The fix: size generously the snapshot area when the origin is very active, and watch its Data% during its lifetime. LVM can also grow a snapshot automatically, but this extension is disabled by default: lvmconfig shows snapshot_autoextend_threshold=100, the value that turns it off. With snapshot_autoextend_threshold = 70 and snapshot_autoextend_percent = 20 in the activation section of lvm.conf, a 1 GiB snapshot grows to 1.2 GiB once 700 MiB are used, provided dmeventd monitors the volume and the VG has free space. In any case, a snapshot is not meant to live long: create it, use it, remove it.

Classic snapshots or thin snapshots?

The snapshot described here is the classic snapshot: it preallocates a fixed size and becomes invalid if it overflows. When you multiply snapshots (frequent backups, test environments), thin snapshots are more efficient: they preallocate no fixed space and share the pool's blocks.

# Snapshot of a thin volume: no -L size to reserve
sudo lvcreate -s -n lvdata-snap vg_data/thin_lvdata

This size-less form only works for a thin volume. On a classic logical volume, the same command without -L fails with "Please specify either size or extents with snapshots". The risk then moves to the saturation of the thin pool rather than of the snapshot itself. See the LVM thin provisioning guide.

Troubleshooting

Snapshot incidents almost all show up as a precise message or in a lvs column. Start with lvs -o lv_name,attr,origin,data_percent: the attribute and the Data% tell you whether the snapshot still exists, whether it is invalid or whether it is being merged.

Symptom	Likely cause	Fix
lvcreate -s refuses: not enough space	VG full	vgs (VFree), free space or add a disk
Please specify either size or extents with snapshots	-L forgotten on a classic volume	add -L, only a thin volume goes without it
Snapshot in swi-I-s---, cannot be mounted	full snapshot (Data% at 100)	lvremove, recreate it bigger, watch how full it gets
Delaying merge since origin is open	origin still mounted or open	unmount, then lvchange -an and -ay, or wait for the reboot
Snapshots of an origin that has a merging snapshot are not supported	a merge is still running	wait until lvs no longer lists the merged snapshot

Swipe to see more

Key points

• A snapshot (lvcreate -s) freezes a volume at time T, through copy-on-write (only changed blocks are copied).
• It serves for the consistent backup (back up the snapshot while the origin runs) and for the rollback.
• The rollback is done with lvconvert --merge; unmount the origin for an immediate effect, otherwise it applies at the next activation.
• A full snapshot is invalidated: size its area according to the expected writes and watch its Data%.
• For many snapshots, prefer thin snapshots on a thin pool.
• A snapshot is temporary: create, use, remove.

Knowledge check

Check that the essentials of this guide are acquired. The questions only cover what has just been explained here.

Knowledge check

Check what you have learned with this interactive quiz

6 questions

6 min

70% to pass

How it works

• The timer starts when you click Start
• Multiple choice, true/false and short answer questions
• You can move between questions
• Detailed results are shown at the end

Start the quiz

Starts the quiz and the timer

FAQ: frequently asked questions about LVM snapshots

These answers cover the questions that come up most about LVM snapshots: their principle, the rollback, sizing and the choice between a classic and a thin snapshot.

What is an LVM snapshot?

How do you restore an LVM snapshot (rollback)?

What size should an LVM snapshot be?

What happens if an LVM snapshot is full?

Classic or thin LVM snapshot, which one to choose?

×

See in the glossary →