>> - You have the structural consistency of the file system itself >> (directory structure, partial writes to files, superblock, etc). >> LVM and other snapshotters help you with that. > I was always under the impression that an LVM snapshot is not better > than an unclean filesystem, like for example after a power loss. But > this 20 year old document proved me wrong: > > https://tldp.org/HOWTO/LVM-HOWTO/snapshotintro.html
Indeed, but filesystems have worked hard (by carefully ordering writes and with the use of journaling) to make sure the "disk" is always in a consistent state in the case of a power loss. I guess in theory the same could be done to make sure a block-by-block copy of a filesystem is always in a consistent state (maybe with additional constraints such as the block-by-block copy has to be done sequentially from the beginning to the end), but AFAIK nobody has tried/bothered to do that. So in practice, if you do a block-by-block copy of a filesystem, you'll get the filesystem equivalent of "screen tearing". If the filesystem is sufficiently idle at the time, the result is often recoverable with `fsck`, but there might be some real loss along the way. BTW: the same holds for higher-levels of the abstraction hierarchy, so an LVM snapshot is what I'd recommend in general, since applications will also try to protect themselves from disastrous losses in case of power loss: a file-by-file copy on a live file-system will result in a copy that will surely look sane at the level of the filesystem structure but may contain files whose content is meaningless because of "tearing", whereas that should usually not happen on a snapshot. === Stefan
