Tumbleweed's Safety Net: Automatic Btrfs Snapshots Before Every Update

The rolling release problem Tumbleweed solves with snapshots

Running zypper dup on a rolling release means you are continuously moving the whole system forward. The useful takeaway is that openSUSE Tumbleweed couples that continuous delivery with an automatic pre-update filesystem snapshot, so a bad update can be undone by booting an earlier system state instead of chasing package downgrades.

This is an engineering decision, not an add-on. The distribution defaults to Btrfs for root and wires Snapper into zypper and transactional-update so each upgrade leaves a recoverable point.

How the safety net is wired in

Tumbleweed delivers packages after openQA testing, but testing cannot cover every hardware and configuration. Snapper creates a pre snapshot before the package transaction and a post snapshot after it succeeds. The snapshots are Btrfs subvolume copies of the root subvolume, typically @, and are managed with retention policies for number and time based snapshots.

Rollback does not rely on the package manager. The bootloader is updated to expose snapshot boot entries, and snapper or YaST Snapshots can make a snapshot the default or undo changes between two snapshots. This reverts filesystem state and bootloader configuration without external media.

Behavior is edition sensitive. Tumbleweed and Leap use Snapper with zypper. MicroOS and Aeon use transactional-update with a different snapshot workflow. Btrfs must be used for root; snapshot rollback as described does not work on ext4.

Check and use the safety net on a Tumbleweed system

Run the following on the local Tumbleweed host as root or with sudo. These commands are for inspection and planning, not for testing.

df -T /

Expected check: the filesystem column should show btrfs. If it does not, snapshot rollback is not available.

snapper list

Expected check: entries with type pre and post around zypper operations. The list shows snapshot number, type, description and creation time. Retention policies control which snapshots are kept.

zypper ref && zypper dup --dry-run

Run this before applying updates to see planned changes. The dry run does not create snapshots. A real zypper dup will trigger Snapper pre and post snapshots via the zypper plugin.

Manual snapshot creation is possible for a known good state:

snapper -c root create --description "before manual change"

Required permissions: root. Risk: snapshots consume disk space in the Btrfs volume. Clean with snapper cleanup or YaST Snapshots when space is constrained.

To revert, boot the system and select a snapshot from the GRUB menu, or from a running system use YaST Snapshots to set a snapshot as default. Undoing changes between two snapshots with snapper undochange requires root and will revert files changed in that interval.

Trade-offs and limits

Snapshot retention and automatic creation policies can change between openSUSE releases and YaST versions. Assumed defaults may differ on older installations.

Rolling release updates are cumulative. Skipping many dup runs increases conflict risk and snapshot size. Rollback reverts system files, not user data changes made after the snapshot. If /home is on the same subvolume as root, user files are reverted too; separate subvolumes avoid that.

Snapshots do not protect against hardware failure or corruption outside Btrfs. They are a logical revert mechanism, not a backup.

Actionable close: verify Btrfs is in use, confirm snapper list shows pre/post snapshots around recent updates, and keep a regular dry run habit before dup. That gives you a verifiable safety net for continuous delivery.