Snapper on SUSE Linux Enterprise Server is set up to serve 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 (approximately more
than 16 GB). Taking snapshots on partitions other than
/ is not enabled by default.
HINT: Enabling Snapper in the Installed System
If you disabled Snapper during the installation, you can enable it at any time later. To do so, create a default Snapper configuration for the root file system by running
tux > sudo snapper -c root create-config /
Afterward enable the different snapshot types as described in Disabling/Enabling Snapshots.
Keep in mind that snapshots require a Btrfs root file system with subvolumes set up as proposed by the installer and a partition size of at least 16 GB.
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
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.
To prevent disks from running out of space, old snapshots are automatically
cleaned up. Refer to
Controlling Snapshot Archiving for details.
Although snapshots themselves do not differ in a technical sense, we distinguish between three types of snapshots, based on the events that trigger them:
A single snapshot is created every hour. Old snapshots are automatically deleted. By default, the first snapshot of the last ten days, months, and years are kept. Timeline snapshots are disabled by default.
Whenever one or more packages are installed with YaST or Zypper, a
pair of snapshots is created: one before the installation starts
Pre) and another one after the installation has finished
Post). In case an important system component such as the
kernel has been installed, the snapshot pair is marked as important
(important=yes). Old snapshots are automatically
deleted. By default the last ten important snapshots and the last ten
regular (including administration snapshots) snapshots
are kept. Installation snapshots are enabled by default.
Whenever you administrate the system with YaST, a pair of snapshots is
created: one when a YaST module is started (
another when the module is closed (
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
Some directories need to be excluded from snapshots for different reasons. The following list shows all directories that are excluded:
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 on IBM POWER and on IBM z Systems, respectively.
If /home does not reside on a separate partition, it is excluded to avoid data loss on rollbacks.
Third-party products usually get installed to /opt. It is excluded to avoid uninstalling these applications on rollbacks.
Contains data for Web and FTP servers. It is excluded to avoid data loss on rollbacks.
All directories containing temporary files and caches are excluded from snapshots.
This directory is used when manually installing software. It is excluded to avoid uninstalling these installations on rollbacks.
The default location for virtual machine images managed with libvirt. Excluded to ensure virtual machine images are not replaced with older versions during a rollback. By default, this subvolume is created with the option no copy on write.
Directories containing mails or mail queues are excluded to avoid a loss of mails after a rollback.
Contains zone data for the DNS server. Excluded from snapshots to ensure a name server can operate after a rollback.
These directories contain database data. By default, these subvolumes are created with the option no copy on write.
Log file location. Excluded from snapshots to allow log file analysis after the rollback of a broken system.
SUSE Linux Enterprise Server comes with a reasonable default setup, which should be sufficient for most use cases. However, all aspects of taking automatic snapshots and snapshot keeping can be configured according to your needs.
Each of the three snapshot types (timeline, installation, administration) can be enabled or disabled independently.
Enabling snapper-c root set-config "TIMELINE_CREATE=yes"
Disabling snapper -c root set-config "TIMELINE_CREATE=no"
Timeline snapshots are enabled by default, except for the root partition.
Enabling: Install the package snapper-zypp-plugin
Disabling: Uninstall the package snapper-zypp-plugin
Installation snapshots are enabled by default.
Enabling: Set USE_SNAPPER to yes in /etc/sysconfig/yast2.
Disabling: Set USE_SNAPPER to no in /etc/sysconfig/yast2.
Administration snapshots are enabled by default.
Taking snapshot pairs upon installing packages with YaST or Zypper is handled by the snapper-zypp-plugin. An XML configuration file, /etc/snapper/zypp-plugin.conf defines, when to make snapshots. By default the file looks like the following:
1 <?xml version="1.0" encoding="utf-8"?> 2 <snapper-zypp-plugin-conf> 3 <solvables> 4 <solvable match="w" important="true">kernel-*</solvable> 5 <solvable match="w" important="true">dracut</solvable> 6 <solvable match="w" important="true">glibc</solvable> 7 <solvable match="w" important="true">systemd*</solvable> 8 <solvable match="w" important="true">udev</solvable> 9 <solvable match="w">*</solvable> 10 </solvables> 11 </snapper-zypp-plugin-conf>
The match attribute defines whether the pattern is a Unix shell-style wild card (w) or a Python regular expression (re).
If the given pattern matches and the corresponding package is marked as important (for example kernel packages), the snapshot will also be marked as important.
Pattern to match a package name. Based on the setting of the match attribute, special characters are either interpreted as shell wild cards or regular expressions. This pattern matches all package names starting with kernel-.
This line unconditionally matches all packages.
With this configuration snapshot, pairs are made whenever a package is installed (line 9). When the kernel, dracut, glibc, systemd, or udev packages marked as important are installed, the snapshot pair will also be marked as important (lines 4 to 8). All rules are evaluated.
To disable a rule, either delete it or deactivate it using XML comments. To prevent the system from making snapshot pairs for every package installation for example, comment line 9:
1 <?xml version="1.0" encoding="utf-8"?> 2 <snapper-zypp-plugin-conf> 3 <solvables> 4 <solvable match="w" important="true">kernel-*</solvable> 5 <solvable match="w" important="true">dracut</solvable> 6 <solvable match="w" important="true">glibc</solvable> 7 <solvable match="w" important="true">systemd*</solvable> 8 <solvable match="w" important="true">udev</solvable> 9 <!-- <solvable match="w">*</solvable> --> 10 </solvables> 11 </snapper-zypp-plugin-conf>
Creating a new subvolume underneath the / hierarchy and permanently mounting it is supported. Such a subvolume will be excluded from snapshots. You need to make sure not to create it inside an existing snapshot, since you would not be able to delete snapshots anymore after a rollback.
SUSE Linux Enterprise Server is configured with the /@/ subvolume which serves as an independent root for permanent subvolumes such as /opt, /srv, /home and others. Any new subvolumes you create and permanently mount need to be created in this initial root file system.
To do so, run the following commands. In this example, a new subvolume /usr/important is created from /dev/sda2.
tux > sudo mount /dev/sda2 -o subvol=@ /mnt tux > sudo btrfs subvolume create /mnt/usr/important tux > sudo umount /mnt
The corresponding entry in /etc/fstab needs to look like the following:
/dev/sda2 /usr/important btrfs subvol=@/usr/important 0 0
HINT: Disable Copy-On-Write (cow)
A subvolume may contain files that constantly change, such as virtualized disk images, database files, or log files. If so, consider disabling the copy-on-write feature for this volume, to avoid duplication of disk blocks. Use the nodatacow mount option in /etc/fstab to do so:
/dev/sda2 /usr/important btrfs nodatacow,subvol=@/usr/important 0 0
To alternatively disable copy-on-write for single files or directories, use the command chattr +C PATH.
Snapshots occupy disk space. To prevent disks from running out of space and thus causing system outages, old snapshots are automatically deleted. By default, up to ten important installation and administration snapshots and up to ten regular installation and administration snapshots are kept. If these snapshots occupy more than 50% of the root file system size, additional snapshots will be deleted. A minimum of four important and two regular snapshots are always kept.
Refer to Section 7.4.1, Managing Existing Configurations for instructions on how to change these values.
Apart from snapshots on Btrfs file systems, Snapper
also supports taking snapshots on thin-provisioned LVM volumes (snapshots
on regular LVM volumes are not supported) formatted
with XFS, Ext4 or Ext3. For more information and setup instructions on LVM
volumes, refer to Section 12.2,
LVM Configuration, (↑Deployment Guide).
To use Snapper on a thin-provisioned LVM volume you need to create a Snapper configuration for it. On LVM it is required to specify the file system with --fstype=lvm(FILESYSTEM). ext3, etx4 or xfs are valid values for FILESYSTEM. Example:
tux > sudo snapper -c lvm create-config --fstype="lvm(xfs)" /thin_lvm
You can adjust this configuration according to your needs as described in Section 7.4.1, Managing Existing Configurations.