Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
documentation.suse.com / The Basic Concepts of Snapper

The Basic Concepts of Snapper

Publication Date: 28 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 Micro.

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 Micro 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
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.

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
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 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
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 Micro 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
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
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

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”.

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
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/.

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
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
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.