Size an LVM snapshot volume based on expected change rate and snapshot lifetime.
A classic (non-thin) LVM snapshot only needs to store copy-on-write blocks — the original contents of any block on the source LV that gets overwritten after the snapshot was taken — not a full copy of the source. Its required size therefore scales with how much data changes during the time the snapshot is kept, not with the source LV's total size. Undersizing it is dangerous: if a COW snapshot fills up, LVM automatically drops it and it becomes permanently invalid, which is why a safety margin above the raw estimate is standard practice.
Snapshot space needed
snapshot_space = source_LV_size × daily_change_rate% × days_kept × (1 + safety_margin%)
The kernel automatically invalidates (drops) the snapshot once its copy-on-write space is exhausted, and it becomes permanently unusable — you cannot resume or top it up after the fact. This is why over-provisioning with a safety margin matters more for snapshots than most other storage sizing decisions.
Yes, with lvextend on the snapshot volume itself, and it's safe to do proactively if you notice usage climbing faster than expected (via lvs -o snap_percent). Extending before it fills is far preferable to losing the snapshot.
Yes, somewhat — every write to the source LV after a snapshot exists must first copy the original block to the snapshot's COW area before the new data is written, adding overhead proportional to the number of active snapshots. This is one reason snapshots are typically kept short-lived (hours to a few days) rather than as long-term backups.