LVM snapshots are meant to capture the filesystem in a frozen state. They are not meant to be a backup in and of themselves. They are, however, useful for obtaining backup images that are consistent because the frozen image cannot and will not change during the backup process. So while you won't use them directly to make long-term backups, they will be of great value in any backup process that you decide to use.

There are a few steps to implement a snapshot. The first is that a new logical volume has to be allocated. The purpose of this volume is to provide an area where deltas (changes) to the filesystem are recorded. This allows the original volume to continue on without disrupting any existing read/write access. The downside to this is that the snapshot area is of a finite size, which means on a system with busy writes, it can fill up rather quickly. For volumes that have significant write activity, you will want to increase the size of your snapshot to allow enough space for all changes to be recorded. If your snapshot overflows (fills up) both the snapshot will halt and be marked as unusable. Should this happen, you will want to release your snapshot so you can get the original volume back online. Once the release is complete, you'll be able to remount the volume as read/write and make the filesystem on it available.

The second thing that happens is that LVM now "swaps" the true purposes of the volumes in question. You would think that the newly allocated snapshot would be the place to look for any changes to the filesystem, after all, it's where all the writes are going to, right? No, it's the other way around. Filesystems are mounted to LVM volume names, so swapping out the name from underneath the rest of the system would be a no-no (because the snapshot uses a different name). So the solution here is simple: When you access the original volume name, it will continue to refer to the live (read/write) version of the volume you did the snapshot of. The snapshot volume you create will refer to the frozen (read-only) version of the volume you intend to back up. A little confusing at first, but it will make sense.

All of this happens in less than 2 seconds. The rest of the system doesn't even notice. Unless, of course, you don't release the snapshot before it overflows...

At some point you will want to release your snapshot to reclaim the space it occupies. Once the release is complete, the snapshot volume is released back into the volume, and the original remains.

I do not recommend pursuing this as a long-term backup strategy. You are still hosting data on the same physical drive that can fail, and recovery of your filesystem from a drive that has failed is no backup at all.

So, in a nutshell:

• Snapshots are good for assisting backups
• Snapshots are not, in and of themselves, a form of backup
• Snapshots do not last forever
• A full snapshot is not a good thing
• Snapshots need to be released at some point
• LVM is your friend, if you use it wisely.

On Linux, btrfs is your main option for snapshots within a filesystem, but is not yet stable, though it does have some fsck and repair tools.

ZFS is another option, from Solaris. While you could in theory use this under Linux, it's mostly implemented in userland only (though there is some work on a kernel-based implementation) and is not in standard Linux distributions.

This LVM answer has some details on the pro's and con's of using LVM snapshots, and some btrfs/ZFS links. With some filesystems (ext3 and XFS), LVM will take care of freezing the FS before it takes the snapshot, but LVM snapshots can have performance problems and still have some bugs.

I don't think LVM is a great solution for your 'quick snapshot of user data' application, and btrfs/ZFS are not yet suitable [as of 2011].

Instead, you might want to look at rsnapshot, which is a user-space tool that efficiently creates snapshots using any filesystem, without using LVM. Because it uses rsync and stores the snapshots under successive directories, using hard links between different snapshots if a file has not changed, it can run surprisingly quickly even on reasonably large sets of files. It is used a lot for backups but can also be used for this sort of user-data snapshot requirement, and with a little setup can enable anyone to restore their snapshotted files, by using read-only NFS or Samba - see this HOWTO section on restoring files. Files can be restored with standard Linux tools as rsnapshot mirrors the source directory into each snapshot directory.

rsnapshot is quite flexible using its standard features, and since it's written in Perl it's quite easy to customise it, e.g. if you want to provide on-demand snapshots. The main drawbacks compared to filesystem snapshots are speed and disk space - each file that changes results in a new copy in the snapshot, whereas filesystem snapshots only copy new blocks in the file.