I'm trying to figure out how LVM snapshots work so I can implement it on my fileserver but I'm having difficulty finding anything on google that explains how it works instead of how to use it for a base backup system.

From what I've read I think it works something like this:

You have an LVM with a primary partition and lots and lots of unallocated freespace not it the partition

Then you take a snapshot and mount it on a new Logical Volume. Snapshots are supposed to be changes so this first snapshot would be a whole copy, correct?

Then, the next day you take another snapshot (this one's partition size doesn't have to be so big) and mount it.

Somehow the LVM keeps track of the snapshots, and doesn't store unchanged bits on the primary volume.

Then you decide that you have enough snapshots and get rid of the first one. I have no idea how this works or how that would affect the next snapshot.

4 Answers
4

LVM snapshots are your basic "copy on write" snapshot solution. The snapshot is really nothing more than asking the LVM to give you a "pointer" to the current state of the filesystem and to write changes made after the snapshot to a designated area.

LVM snapshots "live" inside the volume group hosting the volume subject to the snapshot-- not another volume. Your statement "...lots and lots of unallocated freespace not it the partition" makes it sound like your thinking is that the snapshots "live" outside the volume group subject to snapshot, and that's not accurate. Your volume group lives in a hard disk partition, and the volume being subject to snapshot and any shapshots you've taken live in that volume group.

The normal way that LVM snapshots are used is not for long-term storage, but rather to get a consistent "picture" of the filesystem such that a backup can be taken. Once the backup is done, the snapshot is discarded.

When you create an LVM snapshot you designate an amount of space to hold any changes made while the snapshot is active. If more changes are made than you've designated space for the snapshot becomes unusable and must be discarded. You don't want to leave snapshots laying around because (a) they'll fill up and become unusable, and (b) the system's performance is impacted while a snapshot is active-- things get slower.

Edit:

What Microsoft Volume Shadow Copy Services and LVM snapshots do aren't too tremendously different. Microsoft's solution is a bit more comprehensive (as is typically the case with Microsoft-- for better or for worse their tools and products often seek to solve pretty large problems versus focusing on one thing).

VSS is a more comprehensive solution that unifies support for hardware devices that support snapshots and software-based snapshots into a single API. Further, VSS has APIs to allow applications to be made quiescent through the snapshot APIs, whereas LVM snapshots are just concerned with snapshots-- any quiescing applications is your problem (putting databases into "backup" states, etc).

That's odd, when I tried to create a snapshot I was told there wasn't enough unallocated space on the LVM, I've only used like ~30MB of the partition (488GB total). I tried to create a 10GB snapshot thingy
–
MalfistJul 15 '09 at 16:08

LVM snapshots are an example of a copy-on-write snapshot solution, as Evan said. How it works is a bit different from from Evan implied, but not by a whole lot.

When you have an LVM volume with no snapshots, writes to the volume happen as you'd expect. A block is changed, and that's it.

As soon as you create a snapshot, LVM creates a pool of blocks. This pool also contains a full copy of the LVM metadata of the volume. When writes happen to the main volume such as updating an inode, the block being overwritten is copied to this new pool and the new block is written to the main volume. This is the 'copy-on-write'. Because of this, the more data that gets changed between when a snapshot was taken and the current state of the main volume, the more space will get consumed by that snapshot pool.

When you mount the snapshot, the meta-data written when the snapshot was taken allows the mapping of snapshot pool blocks over changed blocks in the volume (or higher level snapshot). This way when an access comes for a specific block, LVM knows which block access. As far as the filesystem on that volume is concerned, there are no snapshots.

James pointed out one of the faults of this system. When you have multiple snapshots of the same volume, every time you write to a block in the main volume you potentially trigger writes in every single snapshot. This is because each snapshot maintains its own pool of changed blocks. Also, for long snapshot trees, accessing a snapshot can cause quite a bit of computation on the server to figure out which exact block needs to be served for an access.

When you dispose of a snapshot, LVM just drops the snapshot pool and updates the snapshot tree as needed. If the dropped snapshot is part of a snapshot tree, some blocks will be copied to lower level snapshot. If it is the lowest snapshot (or the only one), the pool just gets dropped and the operation is very fast.

Some file-systems do offer in-filesystem snapshots, ZFS and BTRFS are but two of the better known ones. They work similarly, though the filesystem itself manages the changed/unchanged mapping. This is arguably a better way of doing it since you can fsck an entire snapshot family for consistency, which is something you can't do with straight up LVM.

You don't specify whether you are using Linux or HP-UX. In HP-UX, you create a logical volume and mount it as a snapshot of another logical volume. In Linux, you create a logical volume as a snapshot volume.

Removing a snapshot in HP-UX is done by umounting the volume; in Linux it is done by using lvremove to remove the logical volume.

In any case, the changes are the only thing that is stored on your snapshot. The longer the snapshot remains available, the more changes it stocks up - and there is the chance it could fill up if not properly sized or released.

The speed of disk access on a snapshot volume is slower than it would be to a normal volume; you must take that into account.