The Basic Concepts of Snapper
- 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 Micro.
- EFFORT
It takes up to 20 minutes to understand Snapper and its default setup.
- REQUIREMENTS
root
orsudo
privilegesSnapper needs to be installed. It is available on SUSE Linux 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.
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.
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!
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 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 /
.
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.
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
andpost
snapshot pairs:pre
andpost
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.
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.
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 /
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 #
Copyright© 2006–2024 SUSE LLC and contributors. All rights reserved.
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.