Stop your LVM snapshots from killing your disk performance during backups

Technical Briefing | 8/3/2026

You probably use LVM snapshots to get a point-in-time view of a partition before backing it up. It seems elegant enough until the backup starts dragging and your production database starts timing out. That is because copy-on-write overhead is not free, and most people forget that the snapshot volume is essentially a staging area for every single block change that happens while you are running your rsync or tar job.

Why the write performance cliff happens

When you write to the original volume, the kernel must first copy the original block to the snapshot volume before overwriting it on the source. If your snapshot volume is undersized or shared on the same physical spindle as your primary data, you are effectively doubling your I/O pressure for every write operation. I have seen this silently destroy application responsiveness during peak hours just because a nightly backup started a few minutes early.

lvcreate -L 20G -s -n backup_snap /dev/vg0/data

• Use thin provisioning for snapshots so they only consume space on actual writes rather than pre-allocating large chunks of your PV
• Monitor the percent column in lvs output because an overflowing snapshot will drop into error state and potentially hang your original volume
• Place your snapshot volume on a separate physical disk if you are running on mechanical storage to keep the write penalty isolated

Keeping the performance penalty predictable

If you are stuck on older kernels or standard LVM volumes, keep your backup window as short as possible and throttle the I/O of your backup utility. If the backup takes longer than the disk’s capacity to handle the snapshot churn, you are just waiting for a crash. Run a test during the day by hammering the disk with dd while the snapshot is active to see exactly where your latency starts to spike. You will find the breaking point long before your actual production backup does it for you.