Hi Stefan, all,
Am 11.05.2026 um 17:42 schrieb Stefan Monnier:
Arno Lehmann [2026-05-11 14:13:42] wrote:
Because, to get back to the original topic -- an LVM snapshot is *not* an
exact copy of the original volume, and of course much less so of the
partition, disk, or anything else. So a block level dump of an LVM snapshot
is not something you can just dump back as a disaster recovery step.
Interesting. Could you clarify what you mean here?
I've used LVM snapshots in the past then `ddrescue`d the data
back&forth to a target LVM volume and that seemed to work well (and
I assumed it's supposed to work well).
So in which cases is it expected to fail?
I have seen situations where alignment (and probably striping) were
causing issues. I don't have details available any more, but iirc,
depending on how you create file systems, the respective program can
derive some information about block positioning from underlying layers
(i.e. lvm, where those in turn can make use of information about the
underlying block storage). However, that's probably implying a certain
storage complexity where images restores would probably become tricky
for other reasons, too.
Also, I wouldn't say those situations are expected to fail, and I agree
that a snapshot is intended to represent the snapshottee as closely as
possible -- but on the other hand, for backups, intentions are not
always sufficient.
And. of course, it doesn't let gaps between block storage consistency, file
system consistency, file system "cleanness", file contents consistency and
application data consistency vanish.
IME it does provide "filesystem consistency".
To the extent the integration between lvm and the actual file system
works. Which in practice may cover most things I personally ever want to
back up, but that may be because I'm using traditional file systems such
as xfs and the ext family in in LVs. I'm sure I don't want to meet
people who think it's reasonable to put, for example, exFAT or f2fs into
LVs, but I would still be carful to consider the supported set of
combinations.
Definitely not
"filesystem cleanness", indeed. Not sure what you mean by "file
contents consistency" (are you referring to things like ext3's
"data=writeback")?
I think more like the infamous XFS behaviour :-)
But actually a slightly different thing -- when a program has a file
open, you can read or snapshot it at any arbitrary time, and afaik
there's no way to ensure that all buffers are flushed at the time the
snapshot takes place. The lvm-filesystem-integration tries to work into
that direction, but I believe it would be hard to guarantee that.
Essentially, the same problem you often find recommendations to run sync
twice for -- you reduce the window for trouble as much as possible, but
short of enforcing a read-only remount or unmount, there will always be
a slight risk left.
As for "application data consistency", yes, that's
a more complicated question.
Indeed, and it's what many people prefer to ignore, although eventually
it's at least theoretically much easier solved. Well, lots of guesswork
and assumptions here from me, but mixed with at least a bit of experience...
[ Just last week-end my desktop's power supply died while in the middle
of a big set of `git pull` operations. Of course, after I replaced
the power supply, the filesystem was perfectly "consistent" yet many
of the new files ended up empty, including some in the `.git/objects`
directory, leading to errors about missing blobs and whatnot.
Not sure if that was a bug in Git or a misfeature of ext4's default
journaling. ]
Which probably led you do just do a new checkout? Nice example in a way
of how application data consistency can be ensured. Somewhat coarse,
perhaps, but reliable if you have a trustworthy upstream. Where they
hopefully have a good backup, and there we circle back.
Cheers,
Arno
=== Stefan
--
Arno Lehmann
IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück
