You probably set up an LVM snapshot for a quick backup window, watched the transfer finish, and felt good about it. But if you left that snapshot sitting there for too long, you might have noticed the entire disk IO subsystem tanking under load. This bit me in prod years ago when a simple database dump turned into a system-wide performance degradation because the COW area hit 100 percent.

Why the copy-on-write overhead is invisible until it hurts

LVM snapshots work by recording the original data before a write operation overwrites it on the physical volume. When you modify a block on the origin, LVM copies that data to the snapshot volume first. This essentially doubles the write latency for those specific blocks. When your snapshot volume hits its capacity limit, LVM drops the snapshot entirely to protect the filesystem, which is often exactly what you didn’t want.

lvs -o lv_name,vg_name,data_percent,lv_size

• Check the data_percent column in lvs output frequently during backups
• Avoid keeping snapshots longer than the actual backup duration
• Set snapshot sizes to at least 20 percent of the source volume if you anticipate heavy churn

Handling the aftermath of a full snapshot

If you missed the warnings and the snapshot went invalid, do not just delete it and move on. Check your kernel logs for I/O errors or filesystem metadata inconsistencies caused by the sudden drop. Next time you script this, add a trap command to clean up the snapshot automatically even if your backup script hits a non-zero exit code. Your future self will appreciate not having to clean up orphaned, bloated logical volumes at 3 AM.