Stop lying to yourself about your LVM snapshots

Technical Briefing | 10/10/2026

You probably set up LVM snapshots years ago thinking they were a fire-and-forget backup solution. I have seen countless environments where a DBA assumes a snapshot is a valid hot backup, only to find the filesystem metadata is absolute garbage when they try to mount it. Snapshots are not backups. They are crash-consistent states that have no idea what your application was doing in memory when you pulled the trigger.

Why your filesystem is lying to you

When you run an lvcreate for a snapshot, LVM freezes the logical volume just long enough to point to the current extents. But if your database process had half a write operation in flight, that write might not be reflected in the snapshot or, worse, it might be partially written. If you don’t call fsfreeze before taking the snapshot, you are basically hoping your recovery software is smart enough to replay the journals.

fsfreeze -f /var/lib/mysql && lvcreate -L 10G -s -n snap_mysql /dev/vg0/mysql && fsfreeze -u /var/lib/mysql

• Use fsfreeze to force the filesystem to commit all pending buffers to disk first
• Keep your snapshot size large enough so it does not overflow and kill the origin volume
• Never perform a point-in-time recovery without checking the integrity of the LVM metadata
• Automate the snapshot cleanup because stale snapshots will crush your IO throughput

Dealing with the inevitable overflow

The part most guides ignore is that a full snapshot volume effectively kills your origin write performance. If your snapshot volume runs out of space, LVM marks the snapshot invalid, and you just lost your entire backup chain. I have seen this happen during high-load periods when write-heavy tasks caused the copy-on-write overhead to spike unexpectedly. Monitor the percent-full value of your snapshots constantly, or keep the snapshot on a separate physical volume to keep the contention isolated.

If you are still just running lvcreate and walking away, try doing a mock restore of your most critical data tomorrow morning. You will likely find that your backup is less of a safety net and more of a gamble. Stop trusting the snapshot simply because the command finished without an exit error.