As far as I know, LVM makes it possible to take snapshots of a volume. There are also a number of file systems (ZFS, Btrfs, reiserfs, ...) which supports snapshots.
However, I've never understood the difference between LVM snapshots and file system snapshots. If it's possible to take snapshots with LVM, why does someone take their time to implement it in a file system?
Edit: Is any of them preferred in some situations? Why?
Most of these snapshots are copy-on-write snapshots, which are really fast and really cheap (storage-wise) on rarely-updated systems. LVM snapshots are COW snapshots, ZFS/BTRFS both have a COW-mode for snapshots, reiserfs doesn't have snapshots natively, Novell's NSS file-system is also COW, as are Shadow Copy volumes for Windows NTFS volumes.
Copy-on-write snapshots take a copy of the metadata of the target volume into the snapshot pool. Then, depending on which mode of COW they're using, they copy data that would be overwritten by new writes to the snapshot pool before writing the new data.
ZFS and (eventually if not already there) BTRFS have full-snapshot capabilities, which is useful for snapping onto separate media, which in turn is very handy for sneakernet backup systems using removable media. ZFS doesn't call this a "snapshot" though, they leverage ZFS's ability to use zfs send and zfs recv to copy volumes and snapshots over the network to a remote host (or local array).
I prefer filesystem-level snapshot abilities over LVM ones because I better trust the filesystem itself to handle the process cleanly. However, in the lack of direct filesystem support, LVM should work just fine in most cases.
COW snapshots are good if you need a point-in-time backup taken really fast for short-term recovery needs. Such as doing a daily, or 4x daily, snap to be kept for a week. This is handy if you need to recover files users accidentally delete, or need to roll-back an entire system to a pre-update config. They can also be used by some backup systems as a fully quiesced filesystem, so backups taken from the snapshot volume don't have to worry about open files getting in the way. The key thing to remember is that the snapshot volumes will be on the same storage as the primary volume, so don't give you anything in case of array failure.
FULL snapshots are good if they're taken to removable or remote media of some kind. If you have networked storage, the target could be a different iSCSI or Fibre Channel array than the one the primary storage is hosted in. This gives you some off-array protection for some kinds of faults. If using removable media, such as a 3TB ESATA drive, you can even use it as a simple backup-to-disk system. These snapshots CAN be on different hardware than their COW brothers, so are useful for disaster-resilience.
On Full vs COW snapshots.
The term 'snapshot' has drifted a bit over the years. This year, I'm pretty sure it means "a Copy-On-Write copy of the original data using block-relocation". By this definition, the "Full" snapshot presented above is not actually a snapshot, it's replication. Some storage vendors have used different definitions of 'snapshot' in the past to describe various block-level operations they perform. Where it gets confusing are systems that use snapshots as part of the replication process.
LVM requires pre-planning. I tend not to use it because it's also another layer of abstraction and is rarely available when I need it. There are other options to clone at a filesystem level (in Linux) without LVM, though. You can utilize Hot Copy from R1Soft to do this. It's a kernel module, but enables you to add this capability on-the-fly.
Very clear issue: LVM's snapshots are not guaranteed to have consistent FS jue due to LVM "knows" nothing about FS it's being payloaded with
Edited (see the comments): — true unless the FS has support for .freeze_fs, otherwise it should be handled by FS gracefully.
As complement to other answers. In FS snapshots you can benefit of FS features like compression and deduplication across all snapshots.
