Everyone loves a good filesystem snapshot. You trigger it, the storage controller takes the load, and you feel safe. But if you are pointing your backup tool at the raw block device of a live PostgreSQL or MySQL data directory without proper quiescing, you are effectively backing up a state of corruption. I have seen this blow up during restores more times than I care to admit. The filesystem might be consistent, but the application state is a mangled mess of partial writes.

Why the snapshot is a liar

When you freeze a block device, the disk doesn’t know about database transactions. It just grabs the pages as they happen to sit in the I/O buffer or on the platter. Your database engine expects to crash-recover from its WAL or redo logs upon startup. If your backup strategy blindly grabs blocks, you are banking on the database engine’s ability to clean up your mess after you restore. If the snapshot caught an inconsistent state across multiple tablespaces, that recovery will fail hard.

psql -c 'SELECT pg_start_backup("backup_label", true);' && lvcreate -s -L 10G -n db_snap /dev/vg0/data && psql -c 'SELECT pg_stop_backup();'

The only way to stay sane

• Force the database into backup mode to flush dirty buffers to disk
• Perform the snapshot only while the backup lock is active
• Test your restore by actually starting the instance from the snapshot data
• Include the WAL segments that were active during the snapshot window

If your backup provider claims it handles this automatically by simply hitting the storage API, make them show you the logs from the database side during the snapshot creation. If you don’t see that transition into backup mode, consider those backups nothing more than a warm fuzzy feeling that will let you down during a total site failure. Next time you run a backup job, watch the database engine logs while the snapshot happens. If you see checkpoints firing or warnings about unexpected shutdowns, stop relying on that snapshot as your primary recovery path.