Most people treat LVM snapshots like a magic bullet for backups. You create the snapshot, run your dump or rsync, and delete it. It works until you get a heavy write spike on the origin volume. That is when the cow (copy-on-write) mechanism turns your performance into a crawl, and if you aren’t careful, the snapshot overflows and invalidates itself right when you need it most.

Why your snapshot is suddenly turning into a bottleneck

When a block changes on your origin volume, LVM has to move the original data to the snapshot volume before overwriting it. This creates a hidden synchronous write penalty. If your snapshot volume is small or your origin is hammered by writes, the snapshot metadata fills up. Once that happens, the snapshot is dead weight and your origin volume often experiences severe latency spikes or becomes read-only depending on your kernel version and settings.

lvs -o +lv_snapshot_percent

• Monitor the snapshot usage percentage constantly during long backup jobs
• Avoid keeping snapshots longer than the time it takes to perform the backup
• Use a separate physical volume for snapshots to prevent I/O contention

Size your COW store for the expected churn

Don’t just allocate 10 percent of the disk and hope for the best. Calculate the worst-case scenario: how many gigabytes will change during the window where the snapshot exists? If you are running a database dump that takes two hours, measure the WAL or transaction log growth in that timeframe and size your snapshot volume to accommodate that plus a safety buffer. Being lazy here is how you end up with a failed backup mid-stream.

Next time you are setting up an LVM-based backup workflow, verify that your monitoring script triggers an alert at 70 percent usage. If you see the percentage jumping rapidly, kill the backup job before it kills your production throughput. You will thank yourself when the I/O wait times remain flat during your next maintenance window.