35

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?

4 Answers 4

25

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.

3
  • «A filesystem-level snapshot is preferable over one via LVM for the simple fact that the filesystem knows how to keep itself consistent during the snapshot process, where LVM can'» — actually, it's turned out to be not true. Check it out: serverfault.com/questions/300961/…
    – poige
    Aug 15, 2011 at 2:16
  • 1
    «ZFS and (eventually if not already there) BTRFS have full-snapshot capabilities» — You should explain what you mean with "full" snapshots. AFAIK, there is no "COW/full" choice for snapshots with ZFS. All snapshots are COW but nevertheless can be saved later on a separate media as a whole file system or volume.
    – jlliagre
    Aug 15, 2011 at 3:27
  • BTRFS doesn't support LVM snapshots FWIW: btrfs.wiki.kernel.org/index.php/…
    – rogerdpack
    Aug 21, 2020 at 17:18
4

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.

3
  • Out of experience, r1soft is a disaster. Leads to kernel panics. Among other things, if you have a policy of upgrading the kernel fast (within a week or more), R1Soft will not release the necessary module for the latest version of the kernel. So upgrading the kernel depends on whether the R1Soft team is ready. Not that clever, really. Please, don't recommend garbage :)
    – Lethargos
    Aug 4, 2021 at 12:50
  • You're responding to a decade-old question and thread. Surely, the options and technology landscape have changed. Read the room.
    – ewwhite
    Aug 4, 2021 at 18:50
  • Indeed. 7 years ago R1Soft must have been even more of a disaster. I responded because this piece of crap is still being offered to clients. Who knows, maybe someone is going to read it, just like I have.
    – Lethargos
    Aug 4, 2021 at 20:37
4

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.

4
  • 2
    False; LVM prods the filesystem to sync itself before taking the snapshot.
    – womble
    Aug 14, 2011 at 21:09
  • 1
    @womble: even after sync, the snapshot is an exact duplicate of an already mounted filesystem; so when you do mount it, it appears as 'not cleanly unmounted' (because it wasn't unmounted), and have to do some corrective action before it's consistent. Of course, that's typically just a journal replay and after the sync, it should be an empty replay; so there's no data loss danger.
    – Javier
    Aug 15, 2011 at 1:08
  • 2
    @womble, 1) Syncing is not enough, since there would be a window for new I/O requests just between of sync and LVM's snapshot handling. It requires kind of blocking. 2) XFS has special feature called "freeze" (xfs_freeze is intended to be used with volume managers and hardware RAID devices that support the creation of snapshots.) — special thing for snapshots, does LVM-2 know about it and use it already? 3) Tell me where either in user-space ( sources.redhat.com/cgi-bin/cvsweb.cgi/LVM2/?cvsroot=lvm2) or in kernel sources I can prove you're right telling us that LVM prods FS to sync.
    – poige
    Aug 15, 2011 at 1:44
  • 11
    ok, I've done my homework and now can answer the 3rd part of my question — actually, LVM uses kernel's freeze_bdev() which as said in its title is to lock a filesystem and force it into a consistent state. So, at least I can say I was probably wrong saying "not guaranteed to have consistent FS", since it's the matter of support freeze_fs 'method' inside FS implementation — some FSes certainly has such a support (EXT3, Reiser3, XFS), and some not (EXT2, for e. g.). Also, it answers the 2nd question — XFS's freeze is quite likely to be automatically handled with LVM.
    – poige
    Aug 15, 2011 at 2:03
1

As complement to other answers. In FS snapshots you can benefit of FS features like compression and deduplication across all snapshots.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .