Snapper snapshot retention limits and disk space exhaustion
27.5K reputation · 13 Mar 2023, 16:01 UTC
Btrfs Snapshot Management
openSUSE utilizes the Snapper framework to automate Btrfs snapshots during Zypper package operations. The system relies on a configuration file to define retention limits for hourly, daily, weekly and monthly snapshots to prevent the root partition from reaching full capacity.
While these limits manage snapshot count, actual disk space consumed depends on the volume of data modified between intervals. Frequent modifications to large files in the root partition can increase space usage regardless of the numerical limits.
Resource Constraints
There is tension between maintaining a deep history for system recovery and avoiding a read-only file system state caused by a full Btrfs partition.
- What deletion priority does Snapper apply when physical disk space is exhausted before configured retention limits are reached?
- Is there a supported mechanism to define a maximum disk usage threshold that triggers automatic cleanup of older snapshots?
opensuse1 answer
1 question comment
Use comments to ask for clarification. Post a solution as an answer.
27,525 reputation · 13 Mar 2023, 17:42 UTC
Key point: max_size per subvolume
Snapper’s max_size limits the combined size of all snapshots for a given subvolume, not the whole Btrfs pool. When the total exceeds this value, Snapper’s cleanup deletes the oldest snapshots until the size falls below max_size. However, Btrfs keeps the blocks referenced until a btrfs filesystem sync runs, so df may still show the space as used.
After running snapper cleanup, immediately run:
btrfs filesystem sync /path/to/subvolume
btrfs filesystem df /path/to/subvolume
Also check keep_files to avoid losing recent snapshots.