The Basic Concepts of Snapper

Publication Date: 27 Sep 2024

WHAT?

This article describes the basic concepts of the Snapper tool that is used to create and manage Btrfs file system snapshots.

WHY?

This article provides a basic overview of Snapper, its supported interfaces and main purposes. It also informs about default settings for snapshots on SUSE Linux Enterprise Server.

EFFORT

It takes up to 20 minutes to understand Snapper and its default setup.

REQUIREMENTS

root or sudo privileges
Snapper needs to be installed. It is available on SUSE Linux Enterprise Server by default.
A root partition (/) size of at least 16 GB. The size of the root partition depends on the product. We strongly recommend 50 GB or more.

Note

This article is the first installment of the series of articles about Snapper. In the subsequent articles, we cover common use cases such as undoing changes, rolling back the system, manually creating and managing snapshots, automatic snapshot cleanup, and more. Each article builds upon the knowledge gained from the previous ones, providing a progressively enhanced understanding of the Snapper tool.

Revision History: The Basic Concepts of Snapper

1 Essential concepts of Btrfs subvolumes and snapshots #

Btrfs subvolumes are separately mountable file systems within a physical partition. The Btrfs file system is set up with subvolumes by default. Snapshots in Btrfs are a type of subvolume that shares data with another subvolume. They are created using the copy-on-write capabilities of Btrfs, which allows them to be quickly created with minimal disk space usage. Snapshots can be used to capture the state of a file system at a particular point in time and to roll back to a previous state if needed.

A Btrfs subvolume has its own independent file and directory hierarchy. Unlike LVM logical volumes, which operate at the block level, Btrfs subvolumes are file extent-based. A snapshot is also considered a subvolume, carrying the initial content of the original subvolume. Subvolumes appear as directories and can be manipulated like any other directory, including being renamed or moved.

One of the primary purposes of subvolumes is to be explicitly included or excluded from snapshots. When using a snapshot to roll back the system, we need to ensure that data such as users' home directories, Web and FTP server contents or log files do not get lost or overwritten during a rollback. This is achieved by excluding certain Btrfs subvolumes from snapshots. Find more information and the list of excluded subvolumes in Section 3.3, “Subvolumes excluded from snapshots”.

2 What is Snapper? #

Snapper is a tool that helps create and manage file system snapshots. File system snapshots allow keeping a copy of the state of a file system at a certain point of time. Snapper can create and compare snapshots, revert between snapshots, and supports automatic snapshot timelines. Snapper never modifies the content of snapshots.

The standard setup of Snapper is designed to allow rolling back system changes. However, you can also use it to create on-disk backups of user data. As the basis for this functionality, Snapper uses two types of file systems:

Btrfs, a copy-on-write file system for Linux that natively supports file system snapshots of subvolumes.
Thinly provisioned LVM volumes formatted with XFS.

Note

You can also boot from Btrfs snapshots.

2.1 What can Snapper do? #

Snapper has a command-line interface and a YaST interface. Both the command-line interface and the YaST interface can be used interchangeably, allowing you to create, delete and compare snapshots, as well as undo changes made between snapshots.

Using Snapper, you can perform the following tasks:

Undo system changes made by zypper and YaST.
Restore files from previous snapshots.
Do a system rollback by booting from a snapshot.
Manually create and manage snapshots, within the running system.
Perform automatic snapshot cleanup.

2.2 Types of snapshots #

There are two aspects according to which snapshots can be classified: snapshot-triggering events and the time of snapshot creation.

Snapshot types based on triggering events #

Although snapshots themselves do not differ in a technical sense, we distinguish between three types of snapshots, based on the events that trigger them.

Installation snapshots

Whenever one or more packages are installed with YaST or Zypper, three snapshots are created:

Snapshot 0 single is created automatically and always refers to the current system, as indicated in the Description column. This snapshot captures the state of the system right after the installation process has concluded.
Snapshot 1 single for root partition (/) is taken automatically with the name first root filesystem. This snapshot is taken after the first set of system updates or configurations.
Snapshot 2 single is taken automatically with the name after installation. This snapshot is created towards the end of the installation process and marked as important. It represents the state of the system after all initial setup has been completed.

Old snapshots are automatically deleted. By default, the last ten important snapshots and the last ten “regular” ones (including administration snapshots) are kept. Installation snapshots are enabled by default. To manually disable installation snapshots, uninstall the package snapper-zypp-plugin.

Administration snapshots

Whenever you make changes to the system using Zypper or YaST, a pair of snapshots is created: one prior to the system change (“pre”) and the other one after the system change (“post”). Old snapshots are automatically deleted. By default, the last ten important snapshots and the last ten “regular” snapshots (including installation snapshots) are kept. Administration snapshots are enabled by default.

Timeline snapshots

A single snapshot is created every hour. Using the YaST OS installation method (default), timeline snapshots are enabled, except for the root file system. You can configure timeline snapshots to be taken at different intervals: hourly, daily, weekly, monthly and yearly. Old snapshots are automatically deleted. By default, the first snapshot of the last ten days, months and years is kept.

Important: Exception for installation and administration snapshot types

Installation and administration snapshot types do not apply to transactional systems.

Note

Timeline and administration snapshots can be enabled or disabled independently.

Snapshot types based on the time of creation #

Among administration and installation snapshots, Snapper recognizes three different types: pre, post and single. These do not differ physically, but Snapper handles them differently.

pre: Snapshot of a file system before a modification. Each pre snapshot corresponds to a post snapshot. For example, this is used for automatic YaST/Zypper snapshots.
post: Snapshot of a file system after a modification. Each post snapshot corresponds to a pre snapshot. For example, this is used for automatic YaST/Zypper snapshots.
single: Stand-alone snapshot. For example, this is used for automatic hourly snapshots. This is the default type when creating snapshots.

This is the list of snapshots directly after a fresh installation of a system with a root partition > 16 GB:

# | Type   | Pre # | Date                     | User | Used Space | Cleanup | Description           | Userdata     
-----+--------+-------+--------------------------+------+------------+---------+-----------------------+--------------
0  | single |       |                          | root |            |         | current               |              
1  | single |       | Thu Mar 24 12:14:34 2022 | root |  32.44 MiB |         | first root filesystem |              
2  | single |       | Thu Mar 24 12:25:55 2022 | root | 280.40 MiB | number  | after installation    | important=yes
45 | pre    |       | Mon Apr 25 17:58:45 2022 | root |  27.52 MiB | number  | zypp(zypper)          | important=yes
46 | post   |    45 | Mon Apr 25 18:00:07 2022 | root |  39.04 MiB | number  |                       | important=yes

2.3 Snapshot creation #

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 on which the snapshot has been taken. It is not possible to store snapshots on a different partition or subvolume.

As a result, partitions containing snapshots need to be larger than partitions not containing snapshots. The exact amount depends strongly on the number of snapshots you keep and the amount of data modifications. As a rule of thumb, give partitions twice as much space as you normally would. To prevent disks from running out of space, old snapshots are automatically cleaned up.

3 Snapper default setup #

Learn about the default setup of Snapper and its default settings.

Snapper is set up as an undo and recovery tool for system changes. By default, the root partition (/) of SUSE Linux Enterprise Server is formatted with Btrfs. Taking snapshots is automatically enabled if the root partition (/) is big enough (more than approximately 16 GB). By default, snapshots are disabled on partitions other than /.

Important

We do not recommend activating snapshots manually after the system has been installed with snapshots. Enabling Snapper after the installation results in a different setup compared to what is described here.

Tip: Checking root partition size

The size of the root partition is product-specific. To find out the disk space that the root partition occupies, run:

> df -h

3.1 Snapper default settings #

By default, Snapper on SUSE Linux Enterprise Server is automatically configured during system installation if the following requirements are met:

Root partition size: > 16 GB
Root partition file system: Btrfs

Snapshots are created for the root partition only, and certain directories are excluded by means of subvolumes. For the list of excluded subvolumes, see Section 3.3, “Subvolumes excluded from snapshots”. For detailed information about the types of snapshots, the time and occasions of their creation, see Section 2.2, “Types of snapshots”.

Snapper provides automatic snapshot cleanup algorithms to prevent running out of space on the root partition. These algorithms differentiate between timeline snapshots and numbered snapshots (administration plus installation snapshot pairs). The cleanup behavior can be configured based on the following criteria:

Number limit: The system can be set to automatically delete old snapshots when a certain count of snapshots is reached.
Age limit: Old snapshots can be deleted if they exceed a certain age, while still preserving a number of snapshots for each time period (hourly, daily, monthly, yearly).
Pre and post snapshot pairs: pre and post snapshot pairs that do not differ can be automatically deleted.

For numbered snapshots, which include administration and installation snapshot pairs, the cleanup is controlled by parameters such as NUMBER_CLEANUP, NUMBER_LIMIT, NUMBER_LIMIT_IMPORTANT, and NUMBER_MIN_AGE. The default values are 2–10 for NUMBER_LIMIT and 4–10 for NUMBER_LIMIT_IMPORTANT, meaning that only the youngest snapshots are kept.

For timeline snapshots, the cleanup is based on the number of snapshots to keep for each type (hourly, daily, weekly, monthly, yearly). For example, the last 24 hourly snapshots, the first daily snapshot from the last seven days, the first snapshot made on the last day of the month for the last twelve months, and so forth. The parameters include TIMELINE_CLEANUP, TIMELINE_MIN_AGE and interval parameters such as TIMELINE_LIMIT_DAILY, TIMELINE_LIMIT_HOURLY and so on.

You can roll back to an existing snapshot at any time by booting from the respective snapshot and making it active afterwards.

Note: Disabling Snapper automatically and manually

If your root partition is smaller than 16 GB, the automatic creation of snapshots as described above is disabled by default. In this case, you can manually create snapshots. Keep an eye on the available disk space.

To disable automatic snapshots even if your root partition is sufficiently sized, disable snapshots manually during the installation in the partition setup step.

3.2 Snapper on root #

When Snapper is configured to operate on root, every Btrfs subvolume is excluded by default.

The default behavior of Snapper is defined in a configuration file that is specific for each partition or Btrfs subvolume. These configuration files reside under /etc/snapper/configs/.

Warning: Enabling Snapper in the installed system

If you disabled Snapper during the installation, it is possible to enable it later. However, enabling Snapper after the installation results in differences in the subvolume layout and variables, among other things. We strongly recommend deciding whether you need snapshots in your system before starting the installation.

3.3 Subvolumes excluded from snapshots #

The primary use case for snapshots is to roll back the system to a previous state. Therefore, there are certain subvolumes (directories) for which snapshotting is disabled.

The following list contains directories that are excluded from snapshots. Depending on your product and architecture, not all of them may be available on your system.

/boot/grub2/i386-pc, /boot/grub2/x86_64-efi, /boot/grub2/powerpc-ieee1275, /boot/grub2/s390x-emu: A rollback of the boot loader configuration is not supported. The directories listed above are architecture-specific. The first two directories are present on AMD64/Intel 64 machines, the latter two are on IBM POWER and on IBM Z, respectively.
/home: If /home does not reside on a separate partition, it is excluded to avoid the loss of user-created data on rollbacks.
/opt, /usr/local: These directories are used when manually installing third-party products. They are excluded to avoid uninstalling these installations on rollbacks.
/srv: Contains data for Web and FTP servers. It is excluded to avoid data loss on rollbacks.
/tmp: All directories containing temporary files and caches are excluded from snapshots.
/var: This directory contains many variable files, including logs, temporary caches, third-party products in /var/opt, and is the default location for virtual machine images and databases. Therefore, this subvolume is created to exclude all of this variable data from snapshots and has copy-on-write disabled.
/run: This directory contains application runtime data and is excluded from snapshots to reduce the size of the snapshot and to avoid including potentially sensitive information.

Tip

The list of subvolumes is product-specific. To see what subvolumes are created under / and therefore see which directories are excluded from the default snapshots behavior, run:

> sudo btrfs subvolume list /

Note: Why is there a space limit?

When creating a snapshot, no physical data copies are created. A snapshot only consists of pointers to the respective data blocks. As long as the snapshot remains consistent with the current system, it occupies almost no additional disk space (apart from the metadata it contains). However, if a file is modified on the system, the changed data is recorded in the snapshot. Over time, as more changes accumulate and the snapshot diverges from the live system, the snapshot's size increases accordingly.

To prevent disks from running full (and the system becoming inoperable as a result), we recommend having a minimal root file system size. The required size depends on system usage:

The frequency of snapshot creation
The duration for which snapshots are retained
The rate of changes to the system

In general, the more snapshots you have, the longer they are kept, and the more frequently the system changes, the larger the root partition needs to be.

4 For more information #

For more information on the Btrfs file system, refer to https://documentation.suse.com/sles/15-SP5/html/SLES-all/cha-filesystems.html#sec-filesystems-major-btrfs and https://wiki.archlinux.org/title/btrfs.

For more information on LVM volumes, refer to https://documentation.suse.com/sles/15-SP5/html/SLES-all/part-lvm.html.

5 Legal Notice #

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”.

For SUSE trademarks, see https://www.suse.com/company/legal/. All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its affiliates. Asterisks (*) denote third-party trademarks.

All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its affiliates, the authors, nor the translators shall be held liable for possible errors or the consequences thereof.