openSUSE Transactional Updates: Using Btrfs Snapshots for Safe Upgrades and Rollback

A routine zypper dup can occasionally pull in a kernel or library change that prevents openSUSE from booting or breaks a critical service. Transactional updates offer a safety net: they apply package changes inside a Btrfs snapshot rather than directly to the running root filesystem, so you can boot the previous state if the new one fails.

The practical takeaway is that on openSUSE Leap 15.4+ and Tumbleweed with the default Btrfs layout, you can run transactional-update instead of ordinary zypper for risky changes, reboot into the result, and still have a bootable fallback in the GRUB menu.

What transactional updates actually do

Transactional updates are not a separate immutable operating system; they are a workflow available on standard openSUSE installations that use Btrfs. A Btrfs subvolume is a separately manageable part of the filesystem, and a snapshot is a point-in-time, read-only copy of that subvolume. Snapper is the openSUSE tool that creates and manages those snapshots. Before applying changes, the tool asks Snapper to create a read-only snapshot of the current root subvolume. Package operations then run against that snapshot. The currently running system stays untouched until you reboot, at which point the new snapshot becomes the default boot target.

This means a failed update does not corrupt the live filesystem. It only produces a new snapshot that you can choose not to boot.

Prerequisites and assumptions

• Btrfs root filesystem. Transactional updates depend on Btrfs subvolumes. On ext4 or XFS they will fail before creating a snapshot. Verify with mount | grep ' on / ' in a terminal; the output should include type btrfs.
• Required packages. snapper and transactional-update must be installed. Check with rpm -q snapper transactional-update as a regular user. If either is missing, install them as root with zypper install snapper transactional-update.
• Free space. Snapshots share data with the original subvolume, but metadata and changed blocks still consume space. Keep at least 10–20% of the root filesystem size free. Check with btrfs filesystem df /.
• Version baseline. This guide assumes Leap 15.4 or newer, or Tumbleweed. Confirm your release with cat /etc/os-release.

Focused procedure

1. Refresh and apply ordinary updates first

Run sudo zypper refresh && sudo zypper update as root. This updates repository metadata and installs routine patches outside the transactional layer, reducing the size of the later snapshot. Expected check: the command finishes without solver errors.

2. Perform the risky change transactionally

For a single package, use sudo transactional-update pkg install <package-name>, replacing <package-name> with the actual package. For a distribution upgrade, use sudo transactional-update dup.

The tool creates a new snapshot pair, applies the changes inside it, and sets that snapshot as the next default boot entry. The running system is not modified. Expected check: the command reports success and snapper list shows a new pre/post pair with numbers higher than any existing entry.

3. Reboot to activate the snapshot

Run sudo reboot. Until the restart completes, the old system remains active. After login, confirm the new snapshot is in use.

Expected checks after reboot

Use the following checks to confirm the update took effect and the system is healthy.

Check	Command	Run as	What to look for
Root filesystem type	mount | grep ' on / '	regular user	line contains type btrfs
Snapshot created	snapper list	regular user	new pre/post pair with higher numbers
Default boot entry	grep menuentry /boot/grub2/grub.cfg	regular user (root if permissions restrict)	entry referencing the new snapshot ID
Failed services	systemctl --failed	regular user	no output, meaning zero failed units
Package version	rpm -q <package-name>	regular user	version matches the intended update

Recovery options when the new snapshot fails

Temporary recovery: boot the previous snapshot

If the system does not boot or a critical service is broken, restart and open the GRUB menu. Select the entry for the previous snapshot, usually found under an advanced or snapshot-specific submenu. This restores the filesystem state captured before the update without deleting the failed snapshot.

Risk: GRUB selection only reverts the root subvolume. If /home or /var are separate Btrfs subvolumes, data written there after the snapshot remains in place and is not rolled back. Non-Btrfs mounts are never affected by this mechanism.

Permanent rollback with snapper

If the previous snapshot boots correctly and you want to make it the default again, run sudo snapper rollback <snapshot-number>, replacing <snapshot-number> with the ID from snapper list. This creates a new snapshot based on the selected state and points the default boot entry at it. Reboot afterward.

Because this changes the default boot target, treat it as a state-changing operation. Confirm the snapshot number before running it.

Limitations and a practical verification plan

• Filesystem dependency. Only Btrfs is supported. Attempting transactional updates on ext4 or XFS will error out before any snapshot is made.
• Space pressure. If the Btrfs pool runs low on space, snapshot creation can fail. Monitor with btrfs filesystem df / before large upgrades.
• Not a backup. Snapshots live on the same physical disk. Disk failure, accidental deletion of the Btrfs pool, or corruption affects both the current system and its snapshots.
• Delayed activation. Changes are invisible until reboot. Services running in the old snapshot continue using old libraries until then.

To verify the safety net works in your environment, perform a low-risk transactional install—such as a small utility—reboot into it, then reboot once more and manually select the previous snapshot from GRUB. If the old system boots and rpm -q <package-name> shows the older version, the rollback path is functional. After that test, use sudo snapper rollback <snapshot-number> only if you want to make the older state permanent.