I'm about to perform an experimental upgrade on my CentOS 5 server. If the upgrade fails, I want to be able to back out the changes to the filesystem. This scenario seems similar to the example in Section 3.8 of the LVM HOWTO for LVM2 read-write snapshots - but the example is rather lacking in the actual how-to.

  1. How would I commit the changes, merging them back into the original partition?

  2. How would I revert the changes, restoring the filesystem back to its original state? Should I assume that I'll need to restart several services, if not outright reboot?

  3. Is it possible to snapshot only certain directories on a partition, or is it a partition-wide operation?

7 Answers 7


LVM2 / device mapper snapshots merge functionality is available if you are running Linux 2.6.33+ and using LVM 2.0.58+:

lvconvert --merge

See this post: http://www.jonnor.com/2010/02/lvm-snapshot-merging-avaliable/

It references http://kernelnewbies.org/Linux_2_6_33 (look at section 5, MD/DM) and LVM changelog at 2.0.58: ftp://sources.redhat.com/pub/lvm2/WHATS_NEW

But I can't tell you yet how to use it properly ;-)

  • dmsetup targets should show snapshot-merge if that is the case the merge-command, applied to the snapshot-lv will revert back to the state where the snapshot was taken.
    – Nils
    Sep 17, 2015 at 14:56
  • 2
    The OP seems confused about committing changes via some kind of merge step. The changes are being committed as the snapshot grows in size. The snapshot (of the changes) is the needed info for backing them out via lvconvert --merge. If the OP is happy with his changes he can delete the snapshot via lvremove.
    – Vince
    Aug 28, 2019 at 17:15

I just tried a snapshot-based upgrade with Ubuntu. And yeah, I needed to reboot several times. First rename the original root-lv to something else, so you can give the snapshot the original name (since an upgrade creates a lot of change and changes are faster on the snapshot than on the original):

 # lvrename lvm root root-old
 # lvcreate -n root -s lvm/root-old -L 10G

The size should be chosen appropriately. Then reboot, so the 'new' lvm/ubuntu gets mounted as root and you can perform the upgrade. Now you can test the new version and even change to the old system by

 # lvrename lvm root root-new
 # lvrename lvm root-old root
 # reboot

If you want to drop the upgrade, just run (from the old system)

# lvremove lvm/root-new

If you want to commit the changes, just run (from the old system)

# lvconvert --merge lvm/root-new

or, from the new system

# lvrename lvm root root-new
# lvconvert --merge lvm/root-new
# lvrename lvm root-old root

followed by a reboot. The system will refuse to do the merge right away, since the volumes are open. So the merge will be started during the boot and continued while you already can work with the system.

Oh, and by the way: When changing between the systems, remember to use the appropriate kernel. Since /boot is not part of lvm, the old and new kernels would be placed there side-by-side.

  • Thanks for your answer. I've just replayed your procedure in a CentOS 7 virtual machine and it worked like a charm. After resetting my virtual machine in the middle of the merging process, the LVM subsystem resumed it while the system was still accessing the upgraded files. Jan 22, 2017 at 16:37
  • Part of this answer seems to suggest committing changes via lvconvert --merge. As the snapshot grows in size the changes are also being committed. An lvconvert --merge reverts (backs out) the changes using the snapshot info.
    – Vince
    Aug 28, 2019 at 17:25
  • This is THE ANSWER. I've crawled through dozens of papers and articles, and only this one was the solution. May 23, 2023 at 11:43

Ok, I think I have it figured out from re-reading the HOWTO 3.8.

  • Read-only snapshots (like LVM1) contain the block-level differences after the snapshot creation - the original still gets changed, but the snapshot retains a representation of the original. Reading from the snapshot presents the data as it appeared at that time.
  • Read-write snapshots (default in LVM2) can be written to: they're a fork of the original partition. Writing to the snapshot doesn't change the original.

The way a snapshot works is a block-level set of changes from the original. So, when the original is written to, the following things happen:

  1. Something tries to write to the original.
  2. Original gets read, and the blocks from the original are copied to the snapshot.
  3. Original gets changed.
  4. Snapshot contains the "reverse-differences" - the changes that make the original look like it did when the snapshot was created.

So, throwing away the snapshot won't affect the original at all - because the original has been changed, and the snapshot just contained a list of those changes.

Answering my own question:

Create a new snapshot with LVM. If the update can be configured to write to the snapshot mount point, use a R/W snapshot. Otherwise, either RO or R/W will do.


  • If writing to the R/W snapshot mount point, commit by writing the snapshot to the original, and revert by throwing away the snapshot.
  • If writing to the original mount point, commit by throwing away the snapshot, and revert by writing from the snapshot to the original.

I still haven't found a tool specifically to perform this merge - and, given that my scenario isn't exactly the intended use of snapshots, there may not be one. It sounds like a job for rdiff.

  • There is no LVM merge tool available yet. It has been in the works, but I don't believe it's complete. Apr 2, 2010 at 20:48
  • the merge tool exists now (at least on Ubuntu Trusty) -- lvconvert --merge <snapshot-name> will "restore" your original disk to that snapshot, and delete that snapshot. You can of course restore it quickly right away.
    – dpb
    Aug 12, 2014 at 18:16

LVM works at the block level. It even 'doesn't know' what a filesystem is. So you cannot snapshot only certain directories, unless a file system from a different LVM volume is mounted there.

When you make an LVM snapshot you actually request 'copy on write' duplicate of a volume. Any block that would be changed on the snapshotted volume will be stored unmodified in the snaphot first. So to 'commit changes' you don't have to do anything. Just remove the snapshot volume.

I don't quite know what is the recommended way to 'revert changes', as I never used LVM in such scenario, but I guess it described well in the LVM documentation somewhere. Whatever it is you will probably need to restart anything that was changed, a reboot might be a good idea.

  1. There is no reason to merge some. Just remove snapshot, source LV stay changed
  2. Merge needed to revert changes lvconvert --merge <snapshot name>
  3. LVM works with block devices. Any FS-related changes should be done by special utilities (xfs_growfs, e2fsck, ...) according to FS type

Snapshot 'freeze' original LV's state. Remove snapshot means forget that state. Merge snapshot means return to that state

But inside LVM it saves rewritten data in snapshot: be sure that snapshot size meet expected amount of changes on LV and snapshot

  • Actually, snapshot does not freeze anything. It records the changes in an extra place so they can be reverted latter if desired.
    – Vince
    Aug 28, 2019 at 17:28

The documentation is confusing. It seems to me that lvcreate --merge means revert all changes, and lvremove means commit the changes. The distinction is in how you use it.

In most cases, you're just using the snapshot as a read only frozen point in time copy of the live volume, and the live volume keeps changing. In this case, if you merge, logically that would mean you're going to overwrite the live volume with the frozen copy, or in other words, merge means rollback changes, and remove means commit changes.

If you write to the snapshot (a new option with LVM2), which is not the default behavior it seems, and probably requires changing configuration elsewhere to make applications write to the snapshot instead of the original volume, then the reverse would be true.

Please be careful when dealing with snapshots, as some people will assume you mean to use them one way and will give you instructions which may destroy your system if you operate under the opposite assumption!

  • 1
    You write to the snapshot simply by mounting the snapshot; what gets mounted where has little to do with LVM defaults - it doesn't care much about what exactly you do with each logical volume, whether it's a snapshot or not, it just tracks whether it's open or not. Aug 3, 2015 at 21:16

Related, but not direct, this may show how snapshots and mergers work.

Using wisdom from golinuxhub.com:


  • LV at /dev/vg/mylvm
  • mounted at /mylvm
  • with its snapshot at /dev/vg/osnap

Input the merge command #

lvconvert --mergesnapshot /dev/vg/osnap


  Delaying merge since origin is open.
  Merging of snapshot vg/osnap will occur on next activation of vg/mylvm.

...So, let's do just that...

unmount the LV #

umount /mylvm

deactivate the LV # (-an = active no)

lvchange -an /dev/vg/mylvm

activate the LV # (-ay = active yes)

lvchange -ay /dev/vg/mylvm

mount the LV #

mount /dev/vg/mylvm /mylvm

Congratulations, your LV mylvm is back where it was when you made the snapshot!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .