Snapper post‑upgrade snapshot retention after manual rollback in openSUSE Leap

Question

When a zypper dup upgrade fails on openSUSE Leap, Snapper creates a pre‑upgrade snapshot that can be rolled back and leaves the failed post‑upgrade snapshot intact for inspection. The release notes note an unresolved decision about whether this failed post‑upgrade snapshot should be automatically removed after a successful manual rollback, leaving the action to the administrator’s discretion.
The goal is to clarify the expected cleanup behavior to avoid uncontrolled Btrfs space consumption while preserving the ability to diagnose upgrade failures. Constraints include limited disk space on the root subvolume, the need for manual intervention in current implementations, and the lack of a defined policy in the documentation.
Should Snapper automatically delete the failed post‑upgrade snapshot after a successful rollback? What conditions should trigger automatic pruning, and how would this impact troubleshooting and space management?

Tasadduq Burney · Answer

Snapper does not automatically delete failed post-upgrade snapshots after a manual rollback. In openSUSE Leap, a rollback simply points the default subvolume back to a previous state; it leaves the failed post-upgrade snapshot intact for manual inspection or eventual automated pruning cycles.

The behavior is intentional by design. When zypper dup runs, Snapper creates a pre-upgrade snapshot and a post-upgrade snapshot. If the upgrade fails and you perform a snapper rollback, the system returns to the pre-upgrade state. However, the post-upgrade snapshot remains in the snapper list because it contains the specific state of the system when the failure occurred, which is critical for diagnosing dependency conflicts, broken packages, or configuration errors that caused the crash.

Manual Cleanup and Space Management
To manage disk space while preserving access to diagnostic data, follow these steps:

Identify the failed snapshot: Run snapper list to find the snapshot created during the failed upgrade (usually marked with a higher number than your rollback target).
  Inspect the failure: Use snapper diff  to view the changes that led to the upgrade failure.
  Manually delete: Once diagnostics are complete, use snapper delete  to reclaim the Btrfs space.

Automatic Pruning Conditions
While Snapper won't delete the snapshot immediately after rollback, your existing global configuration in /etc/snapper/config-root will eventually remove it. Pruning is triggered by the following parameters:

number_root: If the number of root snapshots exceeds this limit, the oldest snapshots are deleted.
  timeline_cleanup: If the snapshot is older than the specified days limit, it will be pruned during the next snapper-cleanup job.

Assumptions and Uncertainty: This explanation assumes you are using the standard Snapper configuration provided with openSUSE Leap. If you have implemented custom scripts to trigger snapper delete based on zypper exit codes, those would override this behavior. It is currently uncertain if a future-wide policy will automate the deletion of "failed" snapshots specifically, as current logic prioritizes data preservation.

Snapper post‑upgrade snapshot retention after manual rollback in openSUSE Leap

1 answer

Snapper does not automatically delete failed post-upgrade snapshots after a manual rollback. In openSUSE Leap, a rollback simply points the default subvolume back to a previous state; it leaves the failed post-upgrade snapshot intact for manual inspection or eventual automated pruning cycles.

Manual Cleanup and Space Management

Automatic Pruning Conditions

Your perspective belongs here.

0 question comments