Recovering openSUSE Systems via Btrfs Snapshots and Snapper

The Problem: System Instability After Updates

A failed package update, a misconfigured system service, or an accidental deletion of a critical library can render a Linux system unbootable or unstable. In traditional filesystems, recovery requires booting from a Live USB and manually restoring files from a backup. openSUSE solves this by using Btrfs (B-tree File System) and the Snapper utility to create atomic snapshots of the root filesystem, allowing you to revert the entire OS state to a known working point in seconds.

Prerequisites

• An openSUSE Leap or Tumbleweed installation using the default Btrfs filesystem.
• Root or sudo privileges for executing Snapper commands.
• A system that is either currently bootable or accessible via the GRUB boot menu.

Understanding the Snapshot Mechanism

Snapper manages Btrfs subvolumes to create point-in-time copies of your system. By default, openSUSE creates "pre" and "post" snapshots whenever zypper (the package manager) is used. These are stored in the /.snapshots directory. It is critical to note that if your /home directory is on a separate partition or subvolume, user data is not rolled back; only system configurations and binaries are reverted.

Scenario 1: Non-Destructive Testing (Read-Only Boot)

If the system is unstable but still boots to the GRUB menu, you can test a previous state without committing to a permanent change.

1. Restart the computer.
2. In the GRUB boot menu, select Start bootloader from a read-only snapshot.
3. Select the snapshot number corresponding to the date and time before the issue occurred.
4. The system will boot into a read-only version of that snapshot. You can verify that the system is stable and check configuration files, but you cannot save changes to the disk in this mode.

Scenario 2: Permanent System Rollback

Once you have identified a working snapshot, you can make it the new default root filesystem.

Run the following command from a terminal (as root or via sudo):

# snapper rollback

What this command does: Snapper identifies the current default subvolume, creates a new snapshot of the current state (for safety), and sets the most recent stable snapshot as the new default boot target. This operation is atomic and does not move data; it changes the Btrfs default subvolume ID.

If you wish to roll back to a specific snapshot number rather than the most recent one, use:

# snapper rollback [snapshot_number]

After running the rollback, you must reboot the system to initialize the new root filesystem.

Managing Disk Space and Snapshot Retention

Because snapshots retain old versions of files, they consume disk space. While Btrfs uses copy-on-write (CoW) to minimize overhead, excessive snapshots can lead to a full disk. To check your current snapshot list and their IDs, run:

# snapper list

To manually remove an unnecessary snapshot, use the delete command. Do not use rm -rf on the /.snapshots directory, as this will corrupt the Btrfs subvolume metadata.

# snapper delete [snapshot_number]

Verification and Diagnostics

To confirm the rollback was successful and the system is running on the intended subvolume, execute the following checks:

• Verify Subvolumes: Run btrfs subvolume list / to see the underlying subvolume structure and ensure the current root is mapped to the expected snapshot.
• Check Snapper History: Run snapper list to see the new snapshot created by the rollback process.
• Test Application State: Verify that the specific package or configuration change that caused the failure is no longer present.

Rollback Recovery

If a snapper rollback leads to an even more unstable state, you can repeat the process. Because Snapper creates a snapshot of the system before performing the rollback, you can always return to the state you were in immediately before the rollback attempt by selecting the corresponding snapshot ID in the GRUB menu or via the command line.