Using openSUSE Btrfs Snapshots with Snapper for Safe System Updates

Problem: A risky update leaves the system unbootable

You run zypper up on an openSUSE Leap or Tumbleweed machine, and after reboot the system fails to start because a newly installed driver conflicts with your hardware. Reinstalling the whole OS would be time‑consuming, and manually tracking down every changed file is error‑prone.

Thesis: openSUSE’s default Btrfs layout combined with Snapper gives you an automatic, rollback‑ready safety net for every zypper transaction.

When the root filesystem is formatted as Btrfs (the default for both Leap and Tumbleweed), Snapper creates read‑only snapshots of the @ (root) and @/home subvolumes before and after each package operation. Because Btrfs uses copy‑on‑write, these snapshots only store the blocks that actually change, making frequent snapshots storage‑efficient while still providing a precise point‑in‑time restore.

How the automatic snapshots work

The snapper-zypp plugin is installed by default and hooks into zypper’s transaction lifecycle. For every zypper call that modifies the system, Snapper:

1. Creates a pre snapshot (numbered N) before the change begins.
2. Runs the requested zypper operation.
3. Creates a post snapshot (numbered N+1) after the operation finishes.

Both snapshots are read‑only subvolumes under .snapshots in the root directory. You can list them with:

# Run as root or with sudo
sudo snapper list

The output shows columns like # (snapshot number), Type (pre/post), Date, and Description (e.g., zypper).

Worked example: installing a test package and rolling it back

This example demonstrates the snapshot lifecycle without claiming any specific test results.

1. Check prerequisites – verify the filesystem and plugins:

# Confirm Btrfs root
mount | grep ' on / ' | grep -q btrfs && echo 'Btrfs root'
# Ensure snapper and the zypper plugin are installed
zypper se -i snapper snapper-zypp

1. List existing snapshots to have a baseline:

sudo snapper list

1. Perform a change** – install a harmless dummy package (replace dummy-pkg with any package you wish to test):

sudo zypper install dummy-pkg

1. Observe the new snapshot pair** – run the list command again; you should see two new entries, a pre and a post snapshot, with descriptions referencing the zypper transaction:

sudo snapper list

1. Roll back to the pre‑snapshot** – choose the pre‑snapshot number shown in the list (e.g., 42):

sudo snapper rollback 42

This command sets the default subvolume to the selected read‑only snapshot and schedules a reboot. After the system comes back up, the state is exactly as it was before the zypper install call.

1. Verify the rollback** – confirm the package is no longer present:

rpm -qa | grep dummy-pkg
# No output indicates the package was removed

Trade‑off: snapshot space consumption

While copy‑on‑write keeps each snapshot lightweight, snapshots grow as data diverges from the snapshot point. If the root Btrfs filesystem fills, snapshot creation can fail, causing zypper transactions to abort and potentially leaving the system in an inconsistent state.

Practical monitoring:

• Check free space with sudo btrfs filesystem df /. Look at the Data, single line for total vs used.
• Set up a simple alert (e.g., via cron) that warns when used exceeds 85 % of total.
• If space is tight, consider:
• Excluding @/home from snapshots by editing /etc/snapper/configs/root and setting SUBVOLUME="" for home, or
• Adjusting the NUMBER_LIMIT and TIMELINE_LIMIT values in the same config to automatically delete older snapshots.

Actionable closing

To make the most of openSUSE’s built‑in safety net:

1. Verify that your installation is using Btrfs on the root partition (mount | grep ' on / ' | grep btrfs).
2. Ensure snapper and snapper-zypp are installed (zypper se -i snapper).
3. Make a habit of running sudo snapper list before major updates to see the latest snapshot numbers.
4. After any update that seems problematic, roll back with sudo snapper rollback <pre‑snapshot‑number> and reboot.
5. Regularly run sudo btrfs filesystem df / to keep an eye on available space and adjust Snapper limits if needed.

By treating each zypper transaction as a snapshot‑protected operation, you can experiment with updates, drivers, or kernel changes knowing that a quick rollback returns the system to a known good state—without reinstalling or manual file recovery.