## TL;DR
An LVM snapshot overflows when writes to the origin during the backup exceed the snapshot exception store, at which point the snapshot is invalidated and the backup reading it fails. Size the snapshot from measured origin write rate times backup duration with headroom, extend it proactively on long jobs, or migrate the workload to thin-provisioned snapshots that share a pool.

```text
lvm snapshot overflow failed the backup
```

## Use this when
- Backup fails when the LVM snapshot becomes invalid or overflows.
- Snapshot use percentage hits 100 percent during long backup windows.
- Short backups succeed; only long or busy-window backups overflow.

## Not for this skill when
- The volume group has no free space to create a snapshot at all. Creation failure, different fix.
- Application consistency inside the snapshot is the problem, not snapshot survival.

## Steps
1. From logs, record how long the backup ran before overflow and the snapshot size in use. Verify: overflow timing and size are known
2. Measure origin write volume during a typical backup window from monitoring or iostat history. Verify: write rate during backups is quantified
3. Recreate the snapshot sized above the measured writes for the full window plus at least 50 percent headroom, within volume group capacity. Verify: new size exceeds the calculated need
4. Add monitoring on snapshot use percentage with an alert at 70 percent during backups. Verify: the alert fires on a test threshold
5. Rerun the long backup and confirm the snapshot stays valid to completion. Verify: backup completes and snapshot use stays below full

## Variant phrasings
### lvm snapshot overflow invalid backup
The invalid phrasing.
### lvm snapshot full exception store size
The sizing variant.
### lvm snapshot ran out of space during backup
The plain wording.

Compatibility: LVM2 on Linux with classic and thin-provisioned snapshots, used under tar, rsync, dump and agent backups.

## Why it happens
Classic LVM snapshots store origin changes in a fixed exception area, one copy per changed block. Busy systems during long backups change more blocks than small default snapshot sizes anticipate, and the moment the area fills, the snapshot is dropped to protect the origin. The backup then reads a vanished device and fails, which makes it look like a backup tool fault.

## Edge cases / pitfalls
- Thin snapshots share a pool and fail differently when the pool fills. Know which type you run.
- Extending a classic snapshot mid-backup works if done before it fills. Automate checks on very long jobs.
- The real cure for chronic overflow is shorter backup windows or changed-block tools, not ever-larger snapshots.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_76A2IKZBe-cNXoLgMjXPkg