Using OpenSUSE Snapper for Quick Rollbacks and Incremental Backups on Btrfs

Problem

When you update or install packages on a Linux system, a single bad transaction can leave the OS in an unusable state. Re‑installing the entire system or manually restoring files is time‑consuming and error‑prone. On openSUSE, the built‑in Snapper tool provides a lightweight way to capture a system snapshot before a transaction and revert to it instantly if something goes wrong.

Snapper Overview

Snapper works exclusively on Btrfs filesystems. It creates snapshots of Btrfs subvolumes, stores them as read‑only subvolumes, and manages them via a unified CLI and YaST GUI. Key features:

• Automatic pre‑ and post‑install snapshots during zypper transactions.
• Incremental snapshots that only record changed blocks.
• Configurable cleanup policies (age, count, free‑space).
• Integration with YaST’s System > Snapshots module.

Configuring Snapper for System Rollbacks

Snapper is pre‑installed on openSUSE Leap and Tumbleweed, but you must enable Btrfs on the root volume. Verify with:

lsblk -f

Look for TYPE=btrfs on the root partition. If you are using a different filesystem, Snapper will not function.

Snapper’s default configuration resides in /etc/snapper/configs. The root config is used for the root subvolume. Edit it to adjust cleanup rules:

sudo nano /etc/snapper/configs/root

Typical settings for a production system:

Parameter	Recommended Value
cleanup_interval_days	30
cleanup_interval_hours	0
max_snapshots	50
max_space_used_percent	90

After editing, reload Snapper:

sudo snapper create --config root --description "Post‑config edit"

Example: Rolling Back After a Bad Update

Suppose you install a package that breaks networking. The following steps demonstrate how Snapper handles the situation.

1. Automatic snapshot creation – During the zypper install the system creates a pre‑snapshot (e.g., system‑snapshot‑001) and a post‑snapshot once the transaction finishes.
2. Check the snapshot list:

sudo snapper -c root list | grep system-snapshot

Output will show snapshot IDs and timestamps. Identify the snapshot taken before the problematic package.

1. Revert to the pre‑snapshot:

sudo snapper rollback 001

Replace 001 with the actual snapshot ID. Snapper will mount the snapshot as the root filesystem and reboot into that state. Verify the rollback by checking the package list:

zypper se -i | grep bad-package

It should no longer appear.

Trade‑offs & Limitations

• Filesystem requirement: Snapper only works on Btrfs. Users on ext4 or XFS must use external backup tools.
• Storage consumption: Snapshots live on the same volume. While incremental, a large number of snapshots can fill up space and fragment the filesystem, potentially degrading performance.
• User data inclusion: By default Snapper snapshots the root subvolume, which may contain user directories. Rolling back will revert user files as well, so careful subvolume design is advised.
• Manual cleanup: If cleanup policies are not configured, snapshots can accumulate indefinitely.

Takeaway

Snapper turns Btrfs snapshots into a first‑class recovery and backup solution for openSUSE. By enabling automatic pre‑/post‑install snapshots and configuring sensible cleanup policies, administrators can protect against accidental breakage and retain an incremental history of system changes without manual scripting.

Next steps for your environment: confirm Btrfs usage, review subvolume boundaries, tweak the root config, and test a rollback in a controlled environment before relying on it for production recovery.