Btrfs snapshots and rollback with snapper on SUSE: pre/post pairs, GRUB boot, and cleanup

Goal

Use snapper's automatic snapshots to inspect what a package change altered, and to recover a SUSE system that a change broke, either by rolling back or by booting an older snapshot directly.

Prerequisites

A Btrfs root filesystem with snapper configured (the default on a SLES/Leap installation with Btrfs); root access; enough free space in the Btrfs volume for snapshot metadata and diverged extents.

Steps

1. Confirm automatic pairing is active: SUSE's documentation states that snapper "is configured to create a pair of snapshots before and after each" run of zypper and YaST, letting you undo changes made by either.
2. List the paired snapshots: sudo snapper list -t pre-post shows matching pre/post numbers with their dates and descriptions, so you can identify exactly which pair covers a given change.
3. To inspect what changed, diff a pair: sudo snapper status <pre>..<post> reports added, modified and deleted files between the two snapshots. sudo snapper undochange <pre>..<post> reverts those files in the running system without a reboot.
4. To return the whole root filesystem to the state before a change, run sudo snapper rollback <pre> and reboot. Per snapper(8), with a number it first creates a read-only snapshot of the current system, then a read-write snapshot of <pre>, and makes that the default subvolume for the next boot, so the rollback itself is reversible. Without a number it instead makes the currently booted snapshot the new default — the form used in step 5, not a way to undo the last change.
5. If the current system will not boot at all, use the bootloader: at the boot menu choose "Bootable snapshots" and select the snapshot to boot, listed most-recent first. The booted snapshot is read-only, so only inspect it; if it works, run sudo snapper rollback (no number) from inside it, reboot, and choose the default boot entry.
6. Old snapshots are removed automatically by the configured cleanup algorithm (number, timeline, or empty-pre-post) in a daily job; adjust its limits (for example NUMBER_LIMIT) in /etc/snapper/configs/root or with snapper set-config. To remove a specific snapshot, use sudo snapper delete <number> rather than deleting subvolumes by hand, which leaves snapper's metadata out of step.

Expected result

snapper list shows the new pre/post pair immediately after a zypper transaction; after snapper rollback and reboot, the filesystem matches the chosen snapshot, and the list contains both the read-only snapshot of the pre-rollback state and the new read-write default.

Limits and test basis

A rollback restores only the root subvolume. SUSE excludes /var (logs, databases, virtual machine images), /home, /opt, /srv, /usr/local and /tmp, among others, so data there is not rolled back and may be newer than the restored binaries; the root filesystem must be Btrfs on a single device. Rollback and boot-menu recovery both require a reboot; plan a maintenance window before testing this on a running service host.