Using openSUSE Btrfs Snapshots and Snapper for Safe System Rollbacks

Problem and Takeaway

A failed system update on openSUSE can leave the machine unbootable, but the distribution’s default Btrfs+Snapper setup creates a snapshot before and after every zypper operation, giving you an instant undo point.

How Snapshots Work

Btrfs uses copy‑on‑write (COW) for its subvolumes, so a snapshot is a lightweight reference to the filesystem at a point in time and consumes almost no space until data changes. Snapper is configured to create a pre‑transaction snapshot and a post‑transaction snapshot for every zypper package operation. The two snapshots are linked, allowing you to compare files or revert only the files that changed.

• Pre‑snapshot: captured automatically before the package transaction begins.
• Post‑snapshot: captured automatically after the transaction finishes successfully.
• Commands such as snapper list show the pair, and snapper undochange lets you revert individual files without a full rollback.

Worked Example

Suppose you run sudo zypper dup to upgrade Tumbleweed and the update fails halfway, leaving the system unbootable.

1. Reboot and select the read‑only snapshot from the GRUB menu entry labeled “OpenSUSE (snapshot)”. This boots the system from the pre‑update snapshot, which is mounted read‑only.
2. Once booted, open a terminal and run sudo snapper rollback. Snapper will make the selected pre‑snapshot the new default subvolume and reboot into it.
3. After the reboot, the system is back to the state before the failed update, and you can retry the upgrade or investigate the cause.

Important checks: after the rollback, run sudo btrfs subvolume list / to verify that the root subvolume is now the one indicated by Snapper, and df -h / to ensure the root partition still has enough free space.

Trade‑offs and Limitations

Snapshot‑based rollback covers the operating system but not user data. By default, /home lives on a separate subvolume or filesystem, so rolling back the root does not restore deleted personal files. Additionally, heavy write workloads such as databases or virtual machine images cause snapshots to grow quickly; openSUSE mitigates this by excluding paths like /var/lib/mysql via dedicated subvolumes. Misconfigured retention policies—keeping too many snapshots on a small root partition—can lead to “disk full” errors, which you can inspect with df -h / and tune in /etc/snapper/configs/root.

Actionable Closing Steps

1. Verify that automatic snapshots are being created: run sudo snapper list after a simple zypper install and confirm a pre‑ and post‑snapshot pair appears.
2. Check the snapshot layout: execute sudo btrfs subvolume list / and review /etc/fstab to see which directories are on separate subvolumes and excluded from snapshots.
3. Test rollback on a disposable virtual machine: create a fresh openSUSE VM, perform a zypper transaction, then simulate a failure and use the GRUB snapshot entry and snapper rollback to restore the system.
4. Review retention settings: run sudo snapper cleanup number on a test machine and observe disk usage with df -h / to ensure you have enough free space before enabling aggressive cleanup.

With these steps you can safely use openSUSE’s built‑in snapshot mechanism as a practical engineering decision for system recovery, while remembering that snapshots are not a substitute for regular backups of important data.