The GRUB 2 version included on SUSE Linux Enterprise Desktop can boot from Btrfs snapshots. Together with Snapper's rollback feature, this allows to recover a misconfigured system. Only snapshots created for the default Snapper configuration (root) are bootable.
IMPORTANT: Supported Configuration
As of SUSE Linux Enterprise Desktop 12 SP4 system rollbacks are only supported if the default subvolume configuration of the root partition has not been changed.
When booting a snapshot, the parts of the file system included in the snapshot are mounted read-only; all other file systems and parts that are excluded from snapshots are mounted read-write and can be modified.
IMPORTANT: Undoing Changes Compared to Rollback
When working with snapshots to restore data, it is important to know that there are two fundamentally different scenarios Snapper can handle:
When undoing changes as described in Section 7.2, Using Snapper to Undo Changes, two snapshots are compared and the changes between these two snapshots are reverted. Using this method also allows to explicitly exclude selected files from being restored.
When doing rollbacks as described in the following, the system is reset to the state at which the snapshot was taken.
To do a rollback from a bootable snapshot, the following requirements must be met. When doing a default installation, the system is set up accordingly.
Requirements for a Rollback from a Bootable Snapshot
The root file system needs to be Btrfs. Booting from LVM volume snapshots is not supported.
The root file system needs to be on a single device, a single partition and a single subvolume. Directories that are excluded from snapshots such as /srv (see Section 7.1.2, Directories That Are Excluded from Snapshots for a full list) may reside on separate partitions.
The system needs to be bootable via the installed boot loader.
To perform a rollback from a bootable snapshot, do as follows:
Boot the system. In the boot menu chooseand select the snapshot you want to boot. The list of snapshots is listed by date—the most recent snapshot is listed first.
Log in to the system. Carefully check whether everything works as expected. Note that you cannot write to any directory that is part of the snapshot. Data you write to other directories will not get lost, regardless of what you do next.
Depending on whether you want to perform the rollback or not, choose your next step:
If the system is in a state where you do not want to do a rollback, reboot to boot into the current system state. You can then choose a different snapshot, or start the rescue system.
To perform the rollback, run
tux > sudo snapper rollback
and reboot afterward. On the boot screen, choose the default boot entry to reboot into the reinstated system. A snapshot of the file system status before the rollback is created. The default subvolume for root will be replaced with a fresh read-write snapshot. For details, see Section 7.3.1, Snapshots after Rollback.
It is useful to add a description for the snapshot with the -d option. For example:
New file system root since rollback on DATE TIME
HINT: Rolling Back to a Specific Installation State
If snapshots are not disabled during installation, an initial bootable snapshot is created at the end of the initial system installation. You can go back to that state at any time by booting this snapshot. The snapshot can be identified by the description after installation.
A bootable snapshot is also created when starting a system upgrade to a service pack or a new major release (provided snapshots are not disabled).
Before a rollback is performed, a snapshot of the running file system is created. The description references the ID of the snapshot that was restored in the rollback.
Snapshots created by rollbacks receive the value number for the Cleanup attribute. The rollback snapshots are therefore automatically deleted when the set number of snapshots is reached. Refer to Section 7.6, Automatic Snapshot Clean-Up for details. If the snapshot contains important data, extract the data from the snapshot before it is removed.
For example, after a fresh installation the following snapshots are available on the system:
root # snapper --iso list Type | # | | Cleanup | Description | Userdata -------+---+ ... +---------+-----------------------+-------------- single | 0 | | | current | single | 1 | | | first root filesystem | single | 2 | | number | after installation | important=yes
After running sudo snapper rollback snapshot 3 is created and contains the state of the system before the rollback was executed. Snapshot 4 is the new default Btrfs subvolume and thus the system after a reboot.
root # snapper --iso list Type | # | | Cleanup | Description | Userdata -------+---+ ... +---------+-----------------------+-------------- single | 0 | | | current | single | 1 | | number | first root filesystem | single | 2 | | number | after installation | important=yes single | 3 | | number | rollback backup of #1 | important=yes single | 4 | | | |
To boot from a snapshot, reboot your machine and choose ↓ and ↑ to navigate and press Enter to activate the selected snapshot. Activating a snapshot from the boot menu does not reboot the machine immediately, but rather opens the boot loader of the selected snapshot.. A screen listing all bootable snapshots opens. The most recent snapshot is listed first, the oldest last. Use the keys
Figure 7-1 Boot Loader: Snapshots
Each snapshot entry in the boot loader follows a naming scheme which makes it possible to identify it easily:
If the snapshot was marked important, the entry is marked with a *.
Operating system label.
Date in the format YYYY-MM-DD.
Time in the format HH:MM.
This field contains a description of the snapshot. In case of a manually created snapshot this is the string created with the option --description or a custom string (see Setting a Custom Description for Boot Loader Snapshot Entries). In case of an automatically created snapshot, it is the tool that was called, for example zypp(zypper) or yast_sw_single. Long descriptions may be truncated, depending on the size of the boot screen.
HINT: Setting a Custom Description for Boot Loader Snapshot Entries
It is possible to replace the default string in the description field of a snapshot with a custom string. This is for example useful if an automatically created description is not sufficient, or a user-provided description is too long. To set a custom string STRING for snapshot NUMBER, use the following command:
tux > sudo snapper modify --userdata "bootloader=STRING" NUMBER
The description should be no longer than 25 characters—everything that exceeds this size will not be readable on the boot screen.
A complete system rollback, restoring the complete system to the identical state as it was in when a snapshot was taken, is not possible.
Root file system snapshots do not contain all directories. See Section 7.1.2, Directories That Are Excluded from Snapshots for details and reasons. As a general consequence, data from these directories is not restored, resulting in the following limitations.
Applications and add-ons installing data in subvolumes excluded from the snapshot, such as /opt, may not work after a rollback, if others parts of the application data are also installed on subvolumes included in the snapshot. Re-install the application or the add-on to solve this problem.
If an application had changed file permissions and/or ownership in between snapshot and current system, the application may not be able to access these files. Reset permissions and/or ownership for the affected files after the rollback.
If a service or an application has established a new data format in between snapshot and current system, the application may not be able to read the affected data files after a rollback.
Subvolumes like /srv may contain a mixture of code and data. A rollback may result in non-functional code. A downgrade of the PHP version, for example, may result in broken PHP scripts for the Web server.
If a rollback removes users from the system, data that is owned by these users in directories excluded from the snapshot, is not removed. If a user with the same user ID is created, this user will inherit the files. Use a tool like find to locate and remove orphaned files.
A rollback of the boot loader is not possible, since all
stages of the boot loader must fit together. This cannot be
guaranteed when doing rollbacks of /boot.