Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 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?


share|improve this question
up vote 9 down vote accepted

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:

It references (look at section 5, MD/DM) and LVM changelog at 2.0.58:

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

share|improve this answer
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 '15 at 14:56

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.

share|improve this answer
Great answer! Thanks for taking the time. – Peter Krnjevic Jun 11 '15 at 3:03

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.

share|improve this answer
There is no LVM merge tool available yet. It has been in the works, but I don't believe it's complete. – Ignacio Vazquez-Abrams Apr 2 '10 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 '14 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.

share|improve this answer

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!

share|improve this answer
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. – Josip Rodin Aug 3 '15 at 21:16

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.