A SUSE Linux Enterprise 15 server installed with the default Btrfs root layout misbehaves after a routine package update. What does SUSE's default snapper integration give you, how do you use it to recover, and what does it not protect?

## What the installer sets up SUSE's installer defaults to Btrfs for the root filesystem with a deliberate subvolume layout, and configures `snapper` against it. Two integrations then come for free: - **Package-manager snapshots.** Every zypper transaction is bracketed by a *pre* snapshot taken before the transaction and a *post* snapshot taken after it, tagged with the command that ran. YaST operations are snapshotted the same way. - **Timeline snapshots and cleanup.** Periodic snapshots plus automatic cleanup algorithms so the set does not grow without bound. Because Btrfs snapshots are cheap references to the existing extents rather than copies, taking one before every update is affordable in a way it would not be on a traditional filesystem — which is the whole reason SUSE can make rollback a routine, supported operation instead of a restore procedure. ## What is snapshotted, and what is deliberately not The subvolume layout is the part people skip, and it is the part that decides whether a rollback helps you. The installer puts the directories that hold *data* — `/home`, `/srv`, `/opt`, and the variable parts of `/var` such as logs, spools and database directories — into subvolumes that are **not** part of the root snapshot. That is intentional. You want to revert the *system* (`/usr`, `/etc`, the installed package set and the RPM database) without also reverting a week of mail, a database's write-ahead log, or your audit logs. But it means a rollback answers exactly one class of incident: **the update broke the system.** It does not answer "the application corrupted its own data". ## The recovery path If the machine still boots: ```bash snapper list # numbered snapshots, type pre/post, the command that ran snapper status 105..106 # exactly which files that update changed snapper diff 105..106 /etc/some.conf snapper rollback 105 # make snapshot 105 the new default, then reboot ``` If it does not boot, the bootloader menu carries a submenu for starting from a read-only snapshot. You select the pre-update snapshot, the system comes up with that root mounted read-only, you verify it is the good state, and then run `snapper rollback` from inside it and reboot to make it permanent. ## What rollback actually does `snapper rollback` does not copy files backwards. It creates a new writable snapshot from the target snapshot and sets it as the default subvolume, so the next boot mounts that as `/`. The previous state is itself kept as a snapshot, so the operation is reversible — you can roll forward again if the rollback turns out to be the wrong diagnosis. A consequence worth stating in an interview: because `/usr` and the RPM database revert together, the package manager's view of the world stays consistent. You do not end up with a database claiming a package version whose files are not on disk, which is exactly the mess that hand-restoring files from a backup produces. ## Limits and the failure modes people actually hit **It is not a backup.** The snapshots share the disk with the data they describe. A failed disk, a destroyed volume, a ransomware event with root — all of them take the snapshots with them. Snapper complements offsite backups; it does not replace them. **Data divergence after rollback.** The single most common real-world disappointment: an application upgrade migrated its database schema, the system is rolled back to the old binaries, and the old binaries now face a migrated database they cannot read. You must have a plan for the data half — the application's own dump, or a coordinated snapshot of its subvolume — and know which order to restore in. **Space.** Snapshots pin old extents, so deleting a large file whose blocks are still referenced by a snapshot frees nothing. On a busy machine the snapshot set can fill the root filesystem, and a full root filesystem is an outage. The handles are the per-configuration cleanup settings under `/etc/snapper/configs/` — how many numbered snapshots to keep, how long to keep timeline snapshots, and a space limit — plus `snapper delete` for one-offs and `snapper cleanup` to run an algorithm now. Reviewing these on a server that updates frequently is ordinary capacity work, not an emergency measure. **Scope of the boot path.** Rolling back returns the kernel and initramfs that were installed at snapshot time, which is what you want after a bad kernel update — but firmware-level and bootloader-level state outside the filesystem is not covered. ## Where SUSE takes this further The same primitive underpins SUSE's transactional model for its immutable variants, where updates are applied to a new snapshot that only becomes active on the next boot, so a failed update never touches the running system at all. Mentioning that shows you understand snapper as the foundation of SUSE's update story rather than as a desktop convenience. ## What the interviewer is checking That you know rollback is a first-class, supported operation on SUSE — that is the distro's genuine differentiator — *and* that you immediately name its boundary. A candidate who says "snapper, so we just roll back" without mentioning that data subvolumes are excluded has not lived through the aftermath.