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

This question already has an answer here:

Everything I read makes me think an lvm snapshot is a direct copy of the logical volume that was snapshot(ed), but how can that be when it takes 10 seconds to snapshot a 90 gig logical volume? If I have a KVM qcow2 disk image on /var and /var is 90 GB at /dev/volgroup1/lv_var. I do a lvcreate -L 90G -n var_snapped -s /dev/volgroup1/lv_var , does that mean I could delete the qcow2 image on var, and then just mount the var_snapped logical volume and copy the one on there over and I would be fine? I don't uynderstand how a 1:1 copy can happen that fast.

share|improve this question

marked as duplicate by Zoredache, Ward, mdpc, Jenny D, Tom O'Connor Apr 12 '13 at 11:19

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

To answer this question we need to establish how LVM works. This is the gist of it;

A Volume Group consists of several Physical Volumes, or pvs. They are again divided into extents. Each extent take up a fixed amount of space on the physical volume - which is specified when creating the Volume Group (or uses a default).

When you create a Logical Volume, you specify how large you want it to be. This allocates the amount of extents in the Volume Group needed to have access to the specified amount of disk space.

Now, you may start to use that volume for something. When you create a snapshot of the volume - you can specify that the snapshot is of a size smaller than the volume you 'copy'. This works because the snapshot-volume references all the extents of the first volume, and only use the newly allocated extents to store the differences between the two. You can tell how much of the snapshot is utilized with the lvs-command.

So, it takes a really short time to take a snapshot, because LVM only creates references to the extents of the first volume - and doesn't copy any data at all.

As a side effect of this, if the difference is larger than the allocated amount of extents - the snapshot is void - and you will see a lot of error messages in dmesg (which are harmless for the first volume).

I hope this helps.

share|improve this answer
I am getting there, but what I am not understanding is, after creating the snapshot, am I working off of the snapshot or the original when I make changes? If I snapshot a directory say /var and then do rm -rf /var/* can I then mount the snapshot and replace everything that was deleted by doing mount /dev/var_snapshot /mnt/varsnap ; cp -p /mnt/varsnap/* /var ? – user160910 Apr 11 '13 at 20:37
If you've allocated the extents to keep that amount of differences tracked: Yes. But if not; The snapshot is the data you will lose first - so you shouldn't rely on the data to be intact over time - unless you allocated the same amount for the snapshot as for the original volume. – Kvisle Apr 11 '13 at 20:39
In the scenario you've sketched in your question, you are safe. – Kvisle Apr 11 '13 at 20:55

The purpose of a snapshot is to act like a copy, but without actually copying everything. Only the data that is modified after creating the snapshot is copied. Initially reads on the snapshot are satisfied by reading the origin. Writes to the snapshot get stored in the snapshot space, and future reads to that data are taken from there instead of the origin. Writes to the origin cause the data being overwritten to be copied to the snapshot, and future reads of that data from the snapshot device will use the copy in the snapshot store.

So yes, if you create a snapshot, then delete a file from the origin, it will still be there in the snapshot ( or vice versa ).

share|improve this answer

In LVM2, snapshots are read/write by default. Read/write snapshots work like read-only snapshots, with the additional feature that if data is written to the snapshot, that block is marked in the exception table as used, and never gets copied from the original volume. This opens up many new possibilities that were not possible with LVM1's read-only snapshots. One example is to snapshot a volume, mount the snapshot, and try an experimental program that change files on that volume. If you don't like what it did, you can unmount the snapshot, remove it, and mount the original filesystem in its place. It is also useful for creating volumes for use with Xen. You can create a disk image, then snapshot it and modify the snapshot for a particular domU instance. You can then create another snapshot of the original volume, and modify that one for a different domU instance. Since the only storage used by a snapshot is blocks that were changed on the origin or the snapshot, the majority of the volume is shared by the domU's.

share|improve this answer
I guess my reading comprehension just sucks or I am too stupid, but I am still confused. After creating the snapshot, will changes to the file(s) be affecting the snapshot or the original volume? – user160910 Apr 11 '13 at 20:32
The extents referenced by the snapshot volume will store the snapshots version of the file - and the extents referenced by the original volume will store the other version of the file. Ref. my answer. – Kvisle Apr 11 '13 at 20:37

The LVM manual is a wonderful thing:

share|improve this answer
You really should be adding more detail to your answers. Answers are expected to be useful if a link dies. Even a brief summary is often useful enough. (I didn't downvote you). – Zoredache Apr 11 '13 at 20:42
Not sure why this isnt closed yet. Google "How does lvm snapshot work" and the very first hit is an exact duplicate of this question, posted and answered on serverfault. – tdk2fe Apr 11 '13 at 21:08
Thanks for noticing that. It would have been useful if you and posted a link to that question as a comment to the question mentioning that it is a duplicate. – Zoredache Apr 11 '13 at 23:06