Don’t let your filesystem snapshots lie to your database

Technical Briefing | 7/16/2026

You spend all night setting up automatic LVM or ZFS snapshots, convinced you have a bulletproof backup strategy. Everything looks great until you try to restore a database from one of those snapshots and find the data is corrupt. That is because the filesystem doesn’t know about the transaction buffers currently sitting in your database RAM. I have seen this blow up enough times to know that if you are just blindly taking block-level snapshots, you are rolling dice with your integrity.

Why consistency matters more than raw storage

When you trigger a snapshot while the database is writing to disk, you often capture a partially written block. Most databases are smart enough to handle crash recovery on boot, but if you restore a snapshot that contains torn pages, you are effectively forcing your database to recover from a hardware failure it never actually experienced. Before you pull that trigger, you have to freeze the I/O or at least place the application in a hot backup mode.

fsfreeze -f /var/lib/mysql && lvcreate -s -n snap_name /dev/vg0/db_lv && fsfreeze -u /var/lib/mysql

• fsfreeze is your best friend to quiesce the filesystem layer
• Flush buffers to disk before the block driver initiates the copy
• Test your recovery by actually mounting the snapshot to a new path

The command above is a basic pattern but keep in mind it doesn’t solve the application state itself. If you are running PostgreSQL or MySQL, you should ideally use their built-in tools like pg_start_backup or FLUSH TABLES WITH READ LOCK. Mixing those application-level commands with a filesystem freeze is the only way to sleep soundly. If you skip this, don’t blame the storage layer when your next restore job fails with a corrupted index error.

Try restoring one of your existing snapshots to a temporary path this weekend. If it doesn’t mount or the database refuses to start because of a header mismatch, you have exactly the warning you need before a real disaster hits. Take the time to automate the flush process now, rather than debugging hex dumps when the pressure is on.