Stop assuming your filesystem snapshots are actually consistent

Technical Briefing | 10/13/2026

You probably have a cron job that snaps your volumes every hour. It is a nice safety blanket, until you actually have to restore a database from one. I once spent an entire Saturday trying to figure out why my restored Postgres cluster refused to start after a snapshot revert, only to realize the disk was perfectly consistent but the application state was total garbage.

Why atomicity isn’t a silver bullet

A block-level snapshot is just a frozen moment in time from the perspective of the kernel. The storage controller doesn’t know about the transaction logs or the WAL buffers sitting in your application’s RAM. If you pull the rug out from under a running app without a freeze command, you are essentially performing a hard power-off. Most modern databases handle crash-recovery, but why gamble when you can force the app to flush its state?

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

• fsfreeze flushes buffers to disk and blocks new writes so the snapshot captures a quiescent state
• The -f flag freezes the filesystem, keeping I/O requests queued until you run the unfreeze command
• Without the unfreeze command, your application will hang indefinitely and likely crash

When to skip the freeze

Do not get paranoid and try to freeze your entire root partition. That is a recipe for system-wide deadlocks during boot or heavy load. Keep the freezing logic strictly scoped to the data directory or the specific mount point where the application stores its state. If you are using a managed service or a cloud-native block store, check if their API already handles this via a pre-snapshot hook, otherwise you’re just adding latency for no reason.

If your backup script is simple, wrap the freeze in a trap statement. If your script dies mid-execution, your server should automatically unfreeze the filesystem so you don’t wake up to a hung process. It is a small piece of defensive code, but it’s the difference between a reliable backup and a service outage at 3 AM.