Recover a Broken openSUSE System with Snapper Snapshots – Step‑by‑Step Guide

Desired Outcome

Restore a functioning openSUSE system after a failed zypper transaction or an accidental mis‑configuration, without having to reinstall or rebuild from backup. The goal is to revert the root filesystem to the state it was in before the problematic change, while keeping user data in /home and logs in /var/log untouched.

Prerequisites

• The root partition must be on btrfs and use the default Snapper layout (root subvolume /@, /home, /var, etc.).
• Snapper is installed and automatically creates pre and post snapshots for every zypper transaction or YaST change.
• You have physical or console access to the machine and can log in as root or a user with sudo privileges.
• Disk space is sufficient for the snapshots you plan to keep; otherwise, cleanup policies in /etc/snapper/configs/root will prune old snapshots.

Step 1: Locate the Snapshot Pair

Identify the snapshot that captures the state just before the problematic change. Snapper records a pre snapshot before the transaction and a post snapshot after it.

sudo snapper list

Look for a pair where TYPE is pre and post and the DESCRIPTION mentions the failed package or configuration. For example:

  ID  |  TYPE  |  DATE                |  DESCRIPTION
------------------------------------------------------------
  42  |  pre   |  2026-10-14 08:02:15 |  zypper install foo
  43  |  post  |  2026-10-14 08:02:20 |  zypper install foo

Remember the ID of the pre snapshot (in this case, 42).

Step 2: Boot into a Read‑Only Snapshot

Reboot the machine and select the GRUB menu entry that says "Start bootloader from a read-only snapshot". This mounts the chosen snapshot as read‑only, allowing you to test whether the system is stable before committing the rollback.

After booting:

# Verify the snapshot is mounted read‑only
mount | grep ' / ' | awk '{print $4}'
# Expected output: /@ (root) mounted read‑only

Check that critical services start correctly, and confirm that the snapshot number matches the one you intend to roll back to.

Step 3: Perform the Rollback

Once you are satisfied that the snapshot works, switch the default root subvolume to that snapshot. This does not immediately change the running system; it sets the snapshot that will be used at the next boot.

sudo snapper rollback 42

After the command completes, a message like "Rollback to snapshot 42 completed. Reboot required." appears. Do not reboot immediately; the running system remains on the old snapshot until a reboot.

Step 4: Verify the System After Reboot

Reboot normally (choose the standard GRUB entry). The system should now start from the rolled‑back snapshot.

# Check that the default snapshot is now 42
snapper list | grep '^  42  '
# Verify the snapshot is marked as default (a '+' or '(default)' indicator)

Confirm that services are functioning and that the configuration or packages you rolled back are no longer present. For example, if you rolled back a package installation:

zypper info foo
# Expected: package not found

Recovery Options if Rollback Fails

• Re‑create or delete problematic snapshots: If the snapshot pair is corrupted, you can delete it with snapper delete 42 and snapper delete 43 and then retry the rollback on a different snapshot.
• Use a live USB to mount the btrfs filesystem: Boot from a live environment, mount the root subvolume, and manually copy or restore files if Snapper cannot recover the state.
• Restore from backup: Snapshots are not a substitute for full backups. If critical data is lost, revert to the latest external backup.

Limitations and Practical Checks

• Snapper only protects the root subvolume. Directories like /home, /var/log, and /srv are separate subvolumes and are not rolled back.
• Snapshots live on the same Btrfs filesystem; if the disk or filesystem is corrupted, all snapshots are lost.
• Database services that write to /var/lib may be out of sync after a rollback; you may need to rebuild or re‑import data.
• Verify cleanup policies: snapper get-config shows NUMBER_LIMIT and TIMELINE_LIMIT_HOURS values. If snapshots accumulate, adjust or run snapper cleanup.