Snapshot linux ��� ���

CYA – Утилита Snapshot и восстановления системы для Linux

CYA, означает Cover Your Assets, представляет собой бесплатный инструмент с открытым исходным кодом и утилиту восстановления для любых Unix-подобных операционных систем, в которых используется оболочка BASH.

Cya переносится и поддерживает множество популярных файловых систем, таких как EXT2 / 3/4, XFS, UFS, GPFS, reiserFS, JFS, BtrFS и ZFS и т. д.

Обратите внимание, что Cya не будет копировать фактические данные пользователя.

Он только создает резервные копии и восстанавливает саму операционную систему, а не ваши фактические данные пользователя.

Cya – это утилита восстановления системы.

По умолчанию он будет копировать все ключевые каталоги, такие как / bin /, / lib /, / usr /, / var / и несколько других.

Однако вы можете определить свой собственный каталог и путь к файлам для включения в резервную копию, поэтому Cya также подберет их.

Кроме того, можно указать некоторые каталоги / файлы для перехода из резервной копии.

Например, вы можете пропустить / var / logs / если вы не регистрируете эти файлы.

Cya фактически использует метод резервного копирования Rsync под капотом.

Тем не менее, Cya намного проще, чем Rsync при создании резервных копий.

При восстановлении вашей операционной системы Cya откатится от ОС, используя ваш профиль резервного копирования, который вы создали ранее.

Вы можете либо восстановить всю систему, либо только определенные каталоги.

Кроме того, вы можете легко получить доступ к файлам резервных копий даже без полного отката, используя ваш терминал или файловый менеджер.

Еще одна заметная особенность заключается в том, что мы можем создать специальный скрипт восстановления для автоматизации установки ваших системных разделов при восстановлении образа Live CD, USB или сети.

В двух словах, CYA может помочь вам восстановить вашу систему в предыдущих состояниях, когда вы закончите с нарушенной системой, вызванной обновлением программного обеспечения, изменениями конфигурации, вторжениями / хаками и т. д.

Установка CYA

Установка CYA очень проста. Все, что вам нужно сделать, это загрузить бинарный файл Cya и поместить его в свой системный путь.

Это приведет к клонированию последней версии cya в каталоге cya в вашем текущем рабочем каталоге.

Затем скопируйте двоичный файл cya на свой путь или куда захотите.

CYA теперь успешно установлен.

Теперь давайте продолжим и создадим снэпшоты.

Создание снэпшотов

Перед созданием снэпшотов / резервных копий создайте скрипт восстановления с помощью команды:

Сохраните полученный файл recovery.sh на USB-накопителе, который мы будем использовать позже при восстановлении резервных копий.

Этот скрипт поможет вам настроить chrooted среду и смонтировать диски при откате вашей системы.

Теперь давайте создадим снэпшоты

Чтобы создать стандартное резервное копирование, выполните:

Вышеупомянутая команда сохранит три резервных копии перед перезаписью.

Вы можете просмотреть содержимое недавно созданного моментального снимка в разделе /home/cya/points/location.

Чтобы создать резервную копию с настраиваемым именем, которое не будет перезаписано, запустите:

Замените BACKUP_NAME на свое имя.

Чтобы создать резервную копию с пользовательским именем, которое будет перезаписано, выполните следующие действия:

Чтобы создать резервную копию и архивировать и сжать ее, запустите:

Эта команда сохранит резервные копии в местоположении / home / cya / archives.

По умолчанию CYA сохранит свою конфигурацию в каталоге / home / cya /, а моментальные снимки с настраиваемым именем будут сохранены в / home / cya / points / BACKUP_NAME.

Однако вы можете изменить эти параметры, отредактировав файл конфигурации CYA, хранящийся в /home/cya/cya.conf.

Как я уже сказал, CYA по умолчанию не будет делать резервные копии пользовательских данных.

Он будет создавать резервные копии важных системных файлов.

Однако вы можете включить свои собственные каталоги или файлы вместе с системными файлами.

Скажем, например, если вы хотите добавить каталог с именем / home / sk / Downloads в резервную копию, отредактируйте файл /home/cya/cya.conf:

Определите путь к каталогам, который вы хотите включить в резервную копию, как показано ниже.

Помните, что как исходные, так и целевые каталоги должны заканчиваться конечной косой чертой.

В соответствии с приведенной выше конфигурацией CYA скопирует все содержимое каталога / home / sk / Downloads / и сохранит их в каталоге / mnt / backup / sk / (если вы уже создали этот).

Здесь mybackup – это имя профиля.

Сохраните и закройте файл.

Теперь для резервного копирования содержимого каталога / home / sk / Downloads / вам нужно ввести имя профиля (например, mybackup в моем случае) с помощью команды cya mydata, как показано ниже:

Аналогичным образом, вы можете включить несколько пользовательских данных с разными именами профилей.

Все имена профилей должны быть уникальными.

Исключить каталоги

В некоторых случаях вам может не потребоваться резервное копирование всех системных файлов.

Вы можете исключить некоторые несущественные, такие как файлы журналов.

Например, если вы не хотите включать / var / tmp / и / var / logs / directories, добавьте следующее в файл /home/cya/cya.conf.

Аналогичным образом вы можете указать все каталоги по одному, которые вы хотите исключить из резервной копии. После этого сохраните и закройте файл.

Добавление определенных файлов в резервную копию

Вместо резервного копирования целых каталогов вы можете включать определенные файлы из каталога.

Для этого добавьте путь к файлам по одному в файле /home/cya/cya.conf.

Восстановите свою систему

Помните, мы уже создали скрипт восстановления с именем recovery.sh и сохранили его на USB-накопителе?

Да, нам он нужен будет сейчас, чтобы восстановить нашу сломанную систему.

Загрузите свою систему с любого загрузочного CD / DVD-диска, USB-накопителя. Разработчик CYA рекомендует использовать загрузочную среду с той же основной версией, что и ваша установленная среда! Например, если вы используете систему Ubuntu 18.04, используйте live-носители Ubuntu 18.04.

После того, как вы находитесь в живой системе, подключите USB-накопитель, содержащий скрипт recovery.sh.

После установки диска (ов) ваша система / и / home будет смонтирована в каталоге / mnt / cya. Это делается очень легко и обрабатывается автоматически с помощью скрипта recovery.sh для пользователей Linux.

Затем запустите процесс восстановления с помощью команды:

Просто следуйте инструкциям на экране. Как только восстановление будет завершено, удалите живые медиафайлы и отключите диски и, наконец, перезагрузите систему.

Что делать, если у вас нет или потерял сценарий восстановления? Нет проблем, мы все равно можем восстановить нашу сломанную систему.

Загрузите live медиа.

С live сеанса создайте каталог для монтирования дисков.

Затем смонтируйте свой / и / home (если на другом разделе) в каталог / mnt / cya.

Замените / dev / sda1 и / dev / sda3 на свои правильные разделы (используйте команду fdisk -l для поиска ваших разделов).

Наконец, запустите процесс восстановления с помощью команды:

Источник

Snapshot linux ��� ���

Since Btrfs is the only file system on SUSE Linux Enterprise Server supporting snapshots, it is required on all partitions or subvolumes you want to “ snapshot ” .

4.1.1 Snapshots and Disk Space #

When a snapshot is created, both the snapshot and the original point to the same blocks in the file system. So, initially a snapshot does not occupy additional disk space. If data in the original file system is modified, changed data blocks are copied while the old data blocks are kept for the snapshot. Therefore, a snapshot occupies the same amount of space as the data modified. So, over time, the amount of space a snapshot allocates, constantly grows. As a consequence, deleting files from a Btrfs file system containing snapshots may not free disk space!

Note: Snapshot Location

Snapshots always reside on the same partition or subvolume that has been “ snapshotted ” . It is not possible to store snapshots on a different partition or subvolume.

As a result, partitions containing snapshots need to be larger than “ normal ” partitions. The exact amount strongly depends on the number of snapshots you keep and the amount of data modifications. As a rule of thumb you should consider using twice the size than you normally would.

Tip: Freeing space / Disk Usage

In order to free space on a Btrfs partition containing snapshots you need to delete unneeded snapshots rather than files. Older snapshots occupy more space than recent ones.

Since the df does not show the correct disk usage on Btrfs file systems, you need to use the command btrfs filesystem df MOUNT_POINT. Displaying the amount of disk space a snapshot allocates is currently not supported by the Btrfs tools.

Doing an upgrade from one service pack to another results in snapshots occupying a lot of disk space on the system subvolumes, because a lot of data gets changed (package updates). Manually deleting these snapshots once they are no longer needed is recommended.

Snapper can also be used to create and manage snapshots on thin-provisioned LVM volumes formatted with ext3 or XFS (see Section 4.6, “Using Snapper on Thin-Provisioned LVM Volumes”).

4.2 Using Snapper to Undo System Changes #

Snapper on SUSE Linux Enterprise Server is pre-configured to serve as a tool that lets you undo changes made by zypper and YaST. For this purpose, Snapper is configured to create a pair of snapshots before and after each run of zypper and YaST. Snapper also lets you restore system files that have been accidentally deleted or modified. Hourly backups are created for this purpose.

By default, automatic snapshots as described above are configured for the root partition and its subvolumes. In order to make snapshots available for other partitions such as /home for example, you can create custom configurations.

4.2.1 Undoing YaST and Zypper Changes #

If you set up the root partition with Btrfs during the installation, Snapper—pre-configured for doing rollbacks of YaST or Zypper changes—will automatically be installed. Every time you start a YaST module or a Zypper transaction, two snapshots are created: a “ pre-snapshot ” capturing the state of the file system before the start of the module and a “ post-snapshot ” after the module has been finished.

Using the YaST Snapper module or the snapper command line tool, you can undo the changes made by YaST/zypper by restoring files from the “ pre-snapshot ” . Comparing two snapshots the tools also allow you to see which files have been changed. You can also display the differences between two versions of a file (diff).

Since Linux is a multitasking system, processes other than YaST or Zypper may modify data in the time frame between the pre- and the post-snapshot. If this is the case, completely reverting to the pre-snapshot will also undo these changes by other processes. In most cases this would be unwanted—therefore it is strongly recommended to closely review the changes between two snapshots before starting the rollback. If there are changes from other processes you want to keep, select which files to roll back.

Important: Limitations

Make sure you know about Snapper’s limitations before attempting to use its rollback mechanism. See SectionВ 4.4, “Limitations” for details.

Note: Storage Time of Snapshots

By default, the last 100 YaST and Zypper snapshots are kept. If this number is exceeded, the oldest snapshot(s) will be deleted.

ProcedureВ 4.1: Undoing changes using the YaST Snapper module #

Start the Snapper module from the Miscellaneous section in YaST or by entering yast2 snapper .

Make sure Current Configuration is set to root . This is always the case unless you have manually added own Snapper configurations.

Choose a pair of pre- and post-snapshots from the list. Both, YaST and Zypper snapshot pairs are of the type Pre & Post . YaST snapshots are labeled as yast module_name in the Description column ; Zypper snapshots are labeled zypp (zypper) .

Click Show Changes to open the list of files that differ between the two snapshots. The following image shows a list of files that have changed after having added the user tester .

Review the list of files. To display a “ diff ” between the pre- and post-version of a file, select it from the list. The following images shows the changes to /etc/passwd after having added the user tester .

To restore a set of files, select the relevant files or directories by ticking the respective check box. Click Restore Selected and confirm the action by clicking Yes .

To restore a single file, activate its diff view by clicking on its name. Click Restore From First and confirm your choice with Yes .

ProcedureВ 4.2: Undoing changes using the snapper command #

Get a list of YaST and Zypper snapshots by running snapper list -t pre-post . YaST snapshots are labeled as yast module_name in the Description column ; Zypper snapshots are labeled zypp (zypper) .

Get a list of changed files for a snapshot pair with snapper status PRE.. POST. Files with content changes are marked with c , files that have been added are marked with + and deleted files are marked with — . The following example shows a snapshot pair for the installation of the package ncftp .

To display the diff for a certain file, run snapper diff PRE.. POST FILENAME. If you do not specify FILENAME, a diff for all files will be displayed.

To restore one or more files run snapper -v undochange PRE.. POST FILENAMES. If you do not specify a FILENAMES, all changed files will be restored.

4.2.2 Using Snapper to Restore Files from Hourly Backups #

Apart from the YaST and Zypper snapshots, Snapper creates hourly snapshots of the system partition ( / ). You can use these backup snapshots to restore files that have accidentally been deleted or modified beyond recovery. By making use of Snapper’s diff feature you can also find out which modifications have been made at a certain point of time.

Hourly backup snapshots are of the type Single and are marked with the description timeline . To restore files from these snapshots proceed as described in Procedure 4.1, “Undoing changes using the YaST Snapper module” or Procedure 4.2, “Undoing changes using the snapper command”.

Note: Storage Time of Snapshots

By default, the first snapshot of the last ten days, months, and years are kept. For details see Example 4.1, “Example time line configuration”.

4.2.3 Creating and Modifying Snapper Configurations #

The way Snapper behaves is defined in a config file that is specific for each partition or Btrfs subvolume. These config files reside under /etc/snapper/configs/ . The default config installed with Snapper for the / directory is named root . It creates and manages the YaST and Zypper snapshots as well as the hourly backup snapshot for / .

You may create your own configurations for other partitions formatted with Btrfs or existing subvolumes on a Btrfs partition. In the following example we will set up a Snapper configuration for backing up the Web server data residing on a separate, Btrfs -formatted partition mounted at /srv/www .

You can use either snapper itself or the YaST Snapper module to restore files from these snapshots. In YaST you need to select your Current Configuration , while you need to specify your config for snapper with the global switch -c (e.g. snapper -c myconfig list).

To create a new Snapper configuration, run snapper create-config :

Name of config file.

Mount point of the partition or Btrfs subvolume to snapshot.

This command will create a new config file /etc/snapper/config-templates/www-data with reasonable default values (taken from /etc/snapper/config-templates/default ).

Tip: Config Defaults

Default values for a new config are taken from /etc/snapper/config-templates/default . To use your own set of defaults, create a copy of this file in the same directory and adjust it to your needs. To use it, specify the -t option with the create-config command:

4.2.3.1 Adjusting the Config File #

To adjust the config file, you need to modify it with an editor. It contains key/value pairs in the form of key= value . You may only change the value.

Mount point of the partition or subvolume to snapshot. Do not change.

File system type of the partition. Do not change.

Defines whether to automatically delete old snapshots when the total snapshot count exceeds a number specified with NUMBER_LIMIT and an age specified with NUMBER_MIN_AGE . Valid values: yes , no

Note: Limit and Age

NUMBER_LIMIT and NUMBER_MIN_AGE are always evaluated both. Snapshots are only deleted when both conditions are met. If you always want to keep a certain number of snapshots regardless of their age, set NUMBER_MIN_AGE to 0 . On the other hand, if you do not want to keep snapshots beyond a certain age, set NUMBER_LIMIT to 0 .

Defines how many snapshots to keep if NUMBER_CLEANUP is set to yes .

Defines the minimum age in seconds a snapshot must have before it can automatically be deleted.

If set to yes , hourly snapshots are created.This is currently the only way to automatically create snapshots, therefore setting it to yes is strongly recommended. Valid values: yes , no

Defines whether to automatically delete old snapshots when the snapshot count exceeds a number specified with the TIMELINE_LIMIT_* options and an age specified with TIMELINE_MIN_AGE . Valid values: yes , no

Defines the minimum age in seconds a snapshot must have before it can automatically be deleted.

TIMELINE_LIMIT_HOURLY , TIMELINE_LIMIT_DAILY , TIMELINE_LIMIT_MONTHLY , TIMELINE_LIMIT_YEARLY

Number of snapshots to keep for hour, day, month, year.

ExampleВ 4.1: Example time line configuration #

This example configuration enables hourly snapshots which are automatically cleaned up. TIMELINE_MIN_AGE and TIMELINE_LIMIT_* are always evaluated both. In this example, the minimum age of a snapshot, before it can be deleted is set to 30 minutes (1800 seconds). Since we create hourly snapshots, this ensures that only the latest snapshots are kept. If TIMELINE_LIMIT_DAILY is set to not zero, this means that the first snapshot of the day is kept, too.

Snapshots to be Kept #

Hourly: The last ten snapshots that have been made.

Daily: The first daily snapshot that has been made is kept for the last ten days.

Monthly: The first snapshot made on the last day of the month is kept for the last ten months.

Yearly: The first snapshot made on the last day of the year is kept for the last ten years.

4.2.3.2 Using Snapper as Regular User #

By default Snapper can only be used by root . However, there are cases in which certain groups or users need to be able to create snapshots or undo changes by reverting to a snapshot:

a website administrator wants to snapshot /srv/www .

a database administrator wants to snapshot the databases.

a user wants to snapshot her home directory.

For these purposes Snapper configurations that grant permissions to users or/and groups can be created. In addition to this configuration change, the corresponding .snapshots directory needs to be readable and accessible by the specified users.

ProcedureВ 4.3: Enabling Regular Users to Use Snapper #

Note that all steps in this procedure need to be run by root .

If not existing, create a Snapper configuration for the partition or subvolume on which the user should be able to use Snapper. Refer to Section 4.2.3, “Creating and Modifying Snapper Configurations” for instructions. Example:

The configuration file is created under /etc/snapper/configs/ NAME , where NAME is the value you specified with -c/—config in the previous step (for example /etc/snapper/configs/web_data ). Adjust it according to your needs; see SectionВ 4.2.3.1, “Adjusting the Config File” for details.

Set values for ALLOW_USERS and/or ALLOW_GROUPS to grant permissions to users and/or groups, respectively. Multiple entries need to be separated by Space . To grant permissions to the user www_admin for example, enter:

Grant read and access permissions on the snapshot directory PATH/.snapshots. PATH is to be replaced by the subvolume you specified in the first step of this procedure. Example:

The given Snapper configuration can now be used by the specified user(s) and/or group(s). You can test it with the list command, for example:

4.2.4 Disabling Automatic Snapshots #

If you have set up the root partition with Btrfs during the installation, Snapper automatically creates hourly snapshots of the system, as well as pre- and post-snapshots for YaST and zypper transactions. Each of these tasks can be disabled as follows:

Edit /etc/snapper/configs/root and set TIMELINE_CREATE to no :

Uninstall the package snapper-zypp-plugin

Disabling YaST snapshots

Edit /etc/sysconfig/yast2 and set USE_SNAPPER to no :

4.3 Manually Creating and Managing Snapshots #

Snapper is not restricted to creating and managing snapshots automatically by configuration; you can also create snapshot pairs ( “ before and after ” ) or single snapshots manually using either the command line tool or the YaST module.

All Snapper operations are carried out for an existing configuration (see Section 4.2.3, “Creating and Modifying Snapper Configurations” for details). You can only snapshot partitions or volumes for which a configuration exists. By default the system configuration ( root ) is used. If you want to create or manage snapshots for your own configuration you need to explicitly choose it. Use the Current Configuration drop-down menu in YaST or specify the -c on the command line ( snapper -c MYCONFIG COMMAND).

4.3.1 Snapshot Metadata #

Each snapshot consists of the snapshot itself and some metadata. When creating a snapshot you also need to specify the metadata. Modifying a snapshot means changing its metadata—you cannot modify its content. The following metadata is available for each snapshot:

Type : Snapshot type, see Section 4.3.1.1, “Snapshot Types” for details. This data cannot be changed.

Number : Unique number of the snapshot. This data cannot be changed.

Pre Number : Specifies the number of the corresponding pre snapshot. For snapshots of type post only. This data cannot be changed.

Description : A description of the snapshot.

Userdata : An extended description where you can specify custom data in the form of a comma-separated key=value list: reason=testing_stuff, user=tux

Cleanup-Algorithm : Cleanup-algorithm for the snapshot, see Section 4.3.1.2, “Cleanup-algorithms” for details.

4.3.1.1 Snapshot Types #

Snapper knows three different types of snapshots: pre, post, and single. Physically they do not differ, but Snapper handles them differently.

Snapshot of a file system before a modification. Each pre snapshot has got a corresponding post snapshot. Used e.g. for the automatic YaST/zypper snapshots.

Snapshot of a file system after a modification. Each post snapshot has got a corresponding pre snapshot. Used e.g. for the automatic YaST/zypper snapshots.

Stand-alone snapshot. Used e.g. for the automatic hourly snapshots. This is the default type when creating snapshots.

4.3.1.2 Cleanup-algorithms #

Snapper provides three algorithms to clean up old snapshots. The algorithms are executed in a daily cron-job. The cleanup-frequency itself is defined in the Snapper configuration for the partition or subvolume (see Section 4.2.3.1, “Adjusting the Config File” for details).

Deletes old snapshots when a certain snapshot count is reached.

Deletes old snapshots having passed a certain age, but keeps a number of hourly, daily, monthly, and yearly snapshots.

Deletes pre/post snapshot pairs with empty diffs.

4.3.2 Creating Snapshots #

Creating a snapshot is done by running snapper create or by clicking Create in the YaST module Snapper . The following examples explain how to create snapshots from the command line. It should be easy to adopt them when using the YaST interface.

Tip: Snapshot Description

You should always specify a meaningful description in order to later be able to identify its purpose. Even more information can be specified via the user data option.

Creates a stand-alone snapshot (type single) for the default ( root ) configuration with a description. Because no cleanup-algorithm is specified, the snapshot will never be deleted automatically.

snapper —config home create —description «Cleanup in

Creates a stand-alone snapshot (type single) for a custom configuration named home with a description. Because no cleanup-algorithm is specified, the snapshot will never be deleted automatically.

snapper —config home create —description «Daily data backup» —cleanup-algorithm timeline

Creates a stand-alone snapshot (type single) for a custom configuration named home with a description. The file will automatically be deleted when it meets the criteria specified for the time line cleanup-algorithm in the configuration.

snapper create —type pre —print-number —description «Before the Apache config cleanup»

Creates a snapshot of the type pre and prints the snapshot number. First command needed to create a pair of snapshots used to save a “ before ” and “ after ” state.

snapper create —type post —pre-number 30 —description «After the Apache config cleanup»

Creates a snapshot of the type post paired with the pre snapshot number 30 . Second command needed to create a pair of snapshots used to save a “ before ” and “ after ” state.

snapper create —command COMMAND —description «Before and after COMMAND»

Automatically creates a snapshot pair before and after running COMMAND. This option is only available when using snapper on the command line.

4.3.3 Modifying Snapshot Metadata #

Snapper allows you to modify the description, the cleanup algorithm, and the userdata of a snapshot. All other metadata cannot be changed. The following examples explain how to modify snapshots from the command line. It should be easy to adopt them when using the YaST interface.

To modify a snapshot on the command line, you need to know its number. Use snapper list to display all snapshots and their numbers.

The YaST Snapper module already lists all snapshots. Choose one from the list and click Modify .

Modifies the metadata of snapshot 10 for the default ( root ) configuration. The cleanup algorithm is set to timeline .

snapper —config home modify —description «daily backup» -cleanup-algorithm «timeline» 120

Modifies the metadata of snapshot 120 for a custom configuration named home . A new description is set and the cleanup algorithm is unset.

4.3.4 Deleting Snapshots #

To delete a snapshot with the YaST Snapper module, choose a snapshot from the list and click Delete .

To delete a snapshot with the command line tool, you need to know its number. Get it by running snapper list . To delete a snapshot, run snapper delete NUMBER.

Tip: Deleting Snapshot Pairs

When deleting a pre snapshot, you should always delete its corresponding post snapshot (and vice versa).

Deletes snapshot 65 for the default ( root ) configuration.

snapper -c home delete 89 90

Deletes snapshots 89 and 90 for a custom configuration named home .

Tip: Old Snapshots Occupy More Disk Space

If you delete snapshots in order to free space on your hard disk (see Section 4.1.1, “Snapshots and Disk Space” for details), make sure to delete old snapshots first. The older a snapshot is, the more disk space it occupies.

Snapshots are also automatically deleted by a daily cron-job. Refer to Section 4.3.1.2, “Cleanup-algorithms” for details.

4.4 Limitations #

Although being ready for production, Btrfs as well as Snapper are constantly developed further. The following limitations exist at the moment. It is planned to solve these issues in future releases.

4.4.1 Data Consistency #

There is no mechanism to ensure data consistency when creating snapshot. Whenever a file is written (e.g. a database) at the same time the snapshot is created, it will result in a broken or partly written file. Restoring such a file will cause problems. Therefore it is strongly recommended to always closely review the list of changed files and their diffs. Only restore files that really need to belonging to the action you want to roll back.

4.4.2 Reverting User Additions #

Usually /home resides on a separate partition. Such a separate partition is not part of the default configuration for doing YaST rollbacks. Therefore the user’s home partition will not be deleted when reverting a user addition using Snapper. It is strongly recommended to use the YaST User and Group Management tool to remove users.

4.4.3 No Rollback on /boot and Boot Loader Changes #

Currently SUSE Linux Enterprise Server cannot boot from Btrfs partitions. Therefore a separate partition for /boot is created upon the installation when using Btrfs for the system partition. Since /boot does not support snapshots, the following restrictions apply for YaST/zypper rollbacks:

The only file that can be rolled back is the boot loader configuration file in /etc . The main configuration files reside under /boot and cannot be rolled back.

no complete rollback for Kernel installations

The Kernel itself and its initrd are installed in the /boot partition, whereas Kernel modules or sources are installed in /var/lib and /usr/src , respectively. Furthermore, each Kernel installation also changes the boot loader configuration files in /boot. So whenever you do a rollback that involves undoing a Kernel installation, you need to manually remove the Kernel and its initrd from /boot and adjust the boot loader configuration by removing the boot entry for the Kernel.

Источник