You set up LVM or ZFS snapshots because the manual says it is the right thing to do. It feels safe to run that script before a risky production migration. But I have seen enough systems roll back to a state that technically mounts but is logically shredded to know that snapshots are not a substitute for data integrity. The filesystem thinks it is consistent, but your application layers do not agree.

Why the kernel does not care about your database state

The kernel handles blocks, not applications. When you trigger a snapshot, you are grabbing a point-in-time view of the block device. If your database engine had a transaction mid-flight, that partial write ends up in the snapshot. When you revert, the database sees a torn page, panics, and dumps you into recovery mode. This is why you should never rely on raw block snapshots for stateful applications without a coordinated freeze.

fsfreeze -f /var/lib/mysql && lvcreate -s -n backup_snap /dev/vg0/data && fsfreeze -u /var/lib/mysql

• Use fsfreeze to quiesce the VFS layer so the kernel forces all pending buffers to disk.
• Always verify the database WAL logs after you mount a restored snapshot.
• Never perform a live snapshot of a virtual disk without an agent-level quiscence hook.

Proving the restore works before the server dies

If you are not mounting your snapshots in a restricted sandbox to check consistency, you are just collecting digital insurance policies that might be void when you actually need them. Automate a check that mounts the snapshot read-only and runs a basic checksum or table integrity check. If that fails, fix your backup pipeline today, because that 3 AM wake-up call is already scheduled.