Btrfs snapshot retention configuration on OpenSUSE minimal-install servers

Recommended Retention Settings

For low-traffic servers running OpenSUSE Leap or Tumbleweed with minimal installation patterns, the default snapper retention (25 hourly, 10 daily, 5 weekly, 3 monthly) is typically excessive. To reduce storage overhead while maintaining a viable recovery window, the following limits are recommended for the root configuration:

Setting	Recommended Value	Purpose
TIMELINE_LIMIT_HOURLY	6	Covers the last 6 hours of changes.
TIMELINE_LIMIT_DAILY	7	Provides one week of daily recovery points.
TIMELINE_LIMIT_WEEKLY	2	Long-term stability check.
TIMELINE_LIMIT_MONTHLY	1	Minimum monthly archive.
NUMBER_LIMIT	10	Limits total numbered (pre/post) snapshots.
NUMBER_LIMIT_IMPORTANT	5	Protects critical system updates.

If the server is extremely static and storage is critical (e.g., root partition < 20 GiB), consider setting TIMELINE_CREATE="no" to disable automatic timeline snapshots entirely, relying solely on numbered snapshots triggered by zypper updates.

Implementation and Verification

The patterns-minimal package does not alter default snapper behavior; it removes GUI tools but leaves the Btrfs snapshot infrastructure intact. To apply these changes, edit /etc/snapper/configs/root and execute the following to force immediate cleanup:

# Force cleanup of snapshots exceeding new limits
snapper -c root cleanup number
snapper -c root cleanup timeline

Verifying Storage Bounds

To ensure snapshot growth is bounded and the cleanup mechanism is functioning, use these commands:

• Confirm active limits:
  snapper -c root get-config | grep -E "TIMELINE_LIMIT|NUMBER_LIMIT"
• Verify cleanup timer:
  systemctl is-active snapper-cleanup.timer
• Check actual disk usage:
  btrfs filesystem usage /
• Audit snapshot count:
  snapper -c root list --type timeline | wc -l

Technical Assumptions

These recommendations assume the use of the default OpenSUSE Btrfs layout where qgroups are enabled for quota tracking. If btrfs qgroup show / returns no data, per-snapshot size accounting is disabled, and you must rely on btrfs filesystem usage for global disk health. Note that reducing NUMBER_LIMIT too aggressively may delete the "pre" snapshot of a previous update, making it impossible to roll back to a known-good state if a recent update fails.

Diagnostic Detail Required: Please specify if you are using a custom subvolume layout or a separate /home partition, as the home config requires independent tuning to prevent user data snapshots from consuming the same storage pool.