Difference between fsfreeze and lvm snapshot

Question

I heard recently about fsfreeze and I'm very interested in making snapshots of my VM with VMware and get a consistent state of disk using quiescence. All my file-systems are LVM volumes, and man fsfreeze mentions:

fsfreeze is unnecessary for device-mapper devices. The device-mapper (and LVM) automatically freezes filesystem on the device when a snapshot creation is requested. For more details see the dmsetup(8) man page.

But I find fsfreeze much more easy to use than a complex LVM tool where you need to evaluate your snapshot size.

Questions

• Is there a difference?
• Can I still use the command for a LVM volume? Or maybe a physical LVM volume?
• Or am I forced to use the lvm command?

Additional question for the bounty

Does the fsfreeze or lvm snapshot insure a consistent snapshot if used to backup a mysql/oracle/postgrSQL DB?

Some more information

The case here is simple but you need to understand all the concept.
VMWare is capable of taking vm snapshot pretty quickly (less than 5 seconds), and before and after that snapshot executing script to stabilize the vm state and get a consistent vm snaphot. I don't care being able to mount in read-only a lvm snapshot and I don't want to because they are limited to disk size and more-over . What I want is to fsfreeze my filesystems and snapshot the vm and release the lock.
In that case could it be possible to use fsfreeze instead of the lvm snapshot (which are more complex and disk space linked.

Answer 1

From man fsfreeze:

-f, --freeze

This option requests the specified a filesystem to be frozen from new 
modifications. When this is selected, all ongoing transactions in the filesystem 
are allowed to complete, new write system calls are halted, other calls which 
modify the filesystem are halted, and all dirty data, metadata, and log information 
are written to disk. Any process attempting to write to the frozen filesystem will 
block waiting for the filesystem to be unfrozen.

To make a backup, from a mounted file system getting random modifications all the time, freezing the I/O for the duration of the backup is only part of the job to do. That's because unless the file system is really small, or you have an extremely fast backup device, you will most certainly be unable to afford to freeze the whole file system for the entire duration of making the backup.

So, fsfreeze alone is most likely not enough to do what you want. On the other hand, LVM snapshot is exactly what is needed for this job: it takes only a few seconds to "make the backup", then you can take your time to actually copy that backup (the snapshot) to some slow backup device as the LVM snapshot will handle file system blocks getting changed during this long backup process. The only part where fsfreeze would be needed is the snapshot creation part but that part is already handled by LVM itself transparently, so, altogether, all you need to pay attention to is the LVM snapshot.

Backups made by using similar file system freeze or block device snapshot features are considered consistent enough for a well-behaved RDBMS (such as Oracle and its cousins), however, you have to ensure that all the database files get frozen/snapshot at the same point in time. If multiple file systems/LVM volumes are affected, this may neccessitate the help of the RDBMS. Oracle, for instance, provides a BACKUP MODE, which is there to implement a freeze similar to what fsfreeze does, but at the database level.

Answer 2

As @Laszlo noted, freezing is just a part of a backup process. You freeze the filesystem first to force all buffered information that is about to be written to the disk to be flushed to the disk. When filesystem is freezed no data is going to change on the filesystem during the backup process. After you freezed your filesystem you can proceed with backup using tar, dd, dump or whatever (I'm not a backup solutions expert). Also instead of freezing I'd just remount the filesystem as read-only before backing it up if that is an option.

When you create an LVM snapshot you don't need to freeze the filesystem; device-mapper handles it for you. And creating snapshots is not that difficult. The command for creating a snapshot of 2GB in size for /dev/mapper/centos-root LVM logical volume would be:

lvcreate -L 2G -n root-snapshot -s /dev/mapper/centos-root

And the command for restoring from snapshot would be:

lvconvert --merge /dev/mapper/centos-root-snapshot

Note that while merging the snapshot back to its original volume if the original volume is active, merging will occur on the next reboot. The snapshot will no longer exist after merging.

Now a couple words of warning. LVM snapshot copies of a filesystem are virtual copies, not actual media backup for a filesystem. Because LVM snapshots rely on the unchanged data of the original volume they do not provide a substitute for a backup procedure.

LVM snapshots use a COW (copy-on-write) policy. The initial snapshot you take simply contains hard-links to the inodes of your actual data. So long as your data remains unchanged, the snapshot merely contains its inode pointers and not the data itself. Whenever you modify a file or directory that the snapshot points to, LVM automatically clones the data, the old copy referenced by the snapshot, and the new copy referenced by your active system.

If you want to create a backup (not a snapshot) of an LVM logical volume check here for several ways of achieving it.

Also, if an LVM snapshot runs full, the snapshot becomes invalid, since it can no longer track changes on the original volume. Therefore you should regularly monitor the size of the snapshot and increase the size of the snapshot volume (snapshots are fully resizable) to prevent it from getting dropped; or if you find that the snapshot volume is larger than you need, you can reduce its size and free up space.

Answer 3

Are you sure you need to fsfreeze the fs? I've not yet heard of an issue with quiesced snaps of Linux on ESXi -- and I was sure to have heard that the vm-tools will allow the linux VM to quiesce properly via, well, not a fsfreeze but I thought it was more a very short suspend operation.

I've also not need an issue myself with snaps on quiesced live linux VMs running within ESXi. We're using EMC (and 3par when forced) and on both of them on ESXi5 I've not heard anything from my group or a customer suggesting the snap was anything other than what we expected (a good image of the machine at that moment). Should I be worried? Should you?