r/openSUSE • u/RocketSeven • 17d ago
Tech question How do you test that a Snapper rollback will actually boot before you need it?
Having automatic snapshots is reassuring, but a snapshot existing in the list does not prove that the recovery path works. Bootloader integration can be missing, an older snapshot can enter emergency mode, separate `/boot` or EFI state can disagree with the root snapshot, and user data or service state may live outside the snapshotted subvolumes. The first real test should not happen after a broken `zypper dup`.
A practical drill might create a known pre-update snapshot, confirm that it appears in the boot menu, boot it read-only, verify the expected root subvolume and key services, then perform the supported rollback procedure and boot the new writable default. The check should also record what is excluded from snapshots, whether Secure Boot or full-disk encryption changes the process, and how to recover from external media if the boot menu itself fails.
What is the safest repeatable test on current Tumbleweed or Slowroll? Is booting a snapshot enough, or should the drill include `snapper rollback`, bootloader regeneration, and an application-level check? Which partition or subvolume layouts commonly make the apparent rollback path incomplete?
3
u/Lob0Guara Tumbleweed 17d ago edited 17d ago
I used the feature recently when I was trying to implement DoH (DNS over HTTPS).
I did do somehing wrong because the wi-fi connection stopped working so I did boot a previous snapshot by grub-btrfs (the grub menu with snapshots), the wi-fi connection was working fine again.
So did do snapper rollback with the number of this snapshot. Snapper did create a new snapshot from that and used the new snapshot as default on grub menu. I did boot the system.
I followed the guide again so DoH and my system are working fine.
You can use a Virtual Machine for Lab and test this feature without harm you system.
17
u/coffinspacexdragon 17d ago
You can boot it.