Contents
Abstract
Being able to do file system snapshots providing the ability to do
rollbacks on Linux is a feature that was often requested in the past.
Snapper, in conjunction with the Btrfs file system or
thin-provisioned LVM volumes now fills that gap.
Btrfs, a new copy-on-write file system for Linux,
supports file system snapshots (a copy of the state of a subvolume at a
certain point of time) of subvolumes (one or more separately mountable
file systems within each physical partition). Snapper lets you manage
these snapshots. Snapper comes with a command line and a YaST
interface.
By default Snapper and Btrfs on SUSE Linux Enterprise Desktop are set
up to serve as an “undo tool” for system changes made with
YaST and zypper. Before and after running a YaST module or zypper, a
snapshot is created. Snapper lets you compare the two snapshots and
provides means to revert the differences between the two snapshots. The
tools also provide system backups by creating hourly snapshots of the
system subvolumes.
Since Btrfs is the only file system on SUSE Linux Enterprise Desktop
supporting snapshots, it is required on all partitions or subvolumes you
want to “snapshot”.
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!
![]() | 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.
![]() | Freeing space / Disk Usage |
|---|---|
In order to free space on a
Since the df does not show the correct disk usage on
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”).
Snapper on SUSE Linux Enterprise Desktop 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.
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.
![]() | Limitations |
|---|---|
Make sure you know about Snapper's limitations before attempting to use its rollback mechanism. See Section 4.4, “Limitations” for details. | |
![]() | 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 module¶
Start the module from the section in YaST or by entering yast2 snapper.
Make sure is set to . 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 . YaST snapshots are labeled as yast
in the
; Zypper snapshots are labeled
module_namezypp (zypper).
![]() |
Click 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 and confirm the action by clicking .
![]() |
To restore a single file, activate its diff view by clicking on its name. Click and confirm your choice with .
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
in the
; Zypper snapshots are labeled
module_namezypp (zypper).
~ # snapper list -t pre-post
Pre # | Post # | Pre Date | Post Date | Description
------+--------+--------------------------+--------------------------+----------------------+
4 | 5 | Tue Jan 10 14:39:14 2012 | Tue Jan 10 14:39:33 2012 | yast system_settings
65 | 66 | Thu Jan 12 17:18:10 2012 | Thu Jan 12 17:18:23 2012 | zypp(zypper)
68 | 69 | Thu Jan 12 17:25:46 2012 | Thu Jan 12 17:27:09 2012 | zypp(zypper)
73 | 74 | Thu Jan 12 17:32:55 2012 | Thu Jan 12 17:33:13 2012 | yast system_settings
75 | 76 | Thu Jan 12 17:33:56 2012 | Thu Jan 12 17:34:42 2012 | yast users
77 | 92 | Thu Jan 12 17:38:36 2012 | Thu Jan 12 23:13:13 2012 | yast snapper
83 | 84 | Thu Jan 12 22:10:33 2012 | Thu Jan 12 22:10:39 2012 | zypp(zypper)
85 | 86 | Thu Jan 12 22:16:58 2012 | Thu Jan 12 22:17:09 2012 | zypp(zypper)
88 | 89 | Thu Jan 12 23:10:42 2012 | Thu Jan 12 23:10:46 2012 | zypp(zypper)
90 | 91 | Thu Jan 12 23:11:40 2012 | Thu Jan 12 23:11:42 2012 | zypp(zypper)
108 | 109 | Fri Jan 13 13:01:06 2012 | Fri Jan 13 13:01:10 2012 | zypp(zypper)
Get a list of changed files for a snapshot pair with snapper
status
PRE..POST.
Files with content changes are marked with , 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.
~ # snapper status 108..109
+... /usr/bin/ncftp
+... /usr/bin/ncftpbatch
+... /usr/bin/ncftpget
+... /usr/bin/ncftpls
[...]
+... /usr/share/man/man1/ncftpspooler.1.gz
c... /var/cache/zypp/solv/@System/cookie
c... /var/cache/zypp/solv/@System/solv
c... /var/lib/rpm/Basenames
c... /var/lib/rpm/Dirnames
c... /var/lib/rpm/Filemd5s
c... /var/lib/rpm/Group
c... /var/lib/rpm/Installtid
c... /var/lib/rpm/Name
c... /var/lib/rpm/Packages
c... /var/lib/rpm/Providename
c... /var/lib/rpm/Provideversion
c... /var/lib/rpm/Requirename
c... /var/lib/rpm/Requireversion
c... /var/lib/rpm/Sha1header
c... /var/lib/rpm/Sigmd5
c... /var/lib/zypp/SoftLocks
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.
~ # snapper diff 108..109 /var/lib/zypp/SoftLocks
--- /.snapshots/108/snapshot/var/lib/zypp/SoftLocks 2012-01-12 23:15:22.408009164 +0100
+++ /.snapshots/109/snapshot/var/lib/zypp/SoftLocks 2012-01-13 13:01:08.724009131 +0100
@@ -1,4 +1,2 @@
-# zypp::SoftLocksFile generated Thu Jan 12 23:10:46 2012
-#
-ncftp
-#
+# zypp::SoftLocksFile generated Fri Jan 13 13:01:08 2012
+##
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.
~ # snapper -v undochange 108..109
create:0 modify:16 delete:21
undoing change...
deleting /usr/share/man/man1/ncftpspooler.1.gz
deleting /usr/share/man/man1/ncftpput.1.gz
[...]
deleting /usr/bin/ncftpls
deleting /usr/bin/ncftpget
deleting /usr/bin/ncftpbatch
deleting /usr/bin/ncftp
modifying /var/cache/zypp/solv/@System/cookie
modifying /var/cache/zypp/solv/@System/solv
modifying /var/lib/rpm/Basenames
modifying /var/lib/rpm/Dirnames
modifying /var/lib/rpm/Filemd5s
modifying /var/lib/rpm/Group
modifying /var/lib/rpm/Installtid
modifying /var/lib/rpm/Name
modifying /var/lib/rpm/Packages
modifying /var/lib/rpm/Providename
modifying /var/lib/rpm/Provideversion
modifying /var/lib/rpm/Requirename
modifying /var/lib/rpm/Requireversion
modifying /var/lib/rpm/Sha1header
modifying /var/lib/rpm/Sigmd5
modifying /var/lib/zypp/SoftLocks
undoing change done
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 module” or
Procedure 4.2, “Undoing changes using the snapper command”.
![]() | 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”. | |
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
module to restore files from these snapshots.
In YaST you need to select your , 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:
snapper -c www-datacreate-config /srv/www
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).
![]() | Config Defaults |
|---|---|
Default values for a new config are taken from
snapper -c www-data create-config -t my_defaults /srv/www | |
To adjust the config file, you need to modify it with an editor. It
contains key/value pairs in the form of
.
You may only change the key=valuevalue.
SUBVOLUME
Mount point of the partition or subvolume to snapshot. Do not change.
FSTYPE
File system type of the partition. Do not change.
NUMBER_CLEANUP
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
![]() | Limit and Age |
|---|---|
| |
NUMBER_LIMIT
Defines how many snapshots to keep if
NUMBER_CLEANUP is set to yes.
NUMBER_MIN_AGE
Defines the minimum age in seconds a snapshot must have before it can automatically be deleted.
TIMELINE_CREATE
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
TIMELINE_CLEANUP
Defines whether to automatically delete old snapshots when the
snapshot count exceeds a number specified with the
options and an age specified with
TIMELINE_LIMIT_*TIMELINE_MIN_AGE. Valid values:
yes, no
TIMELINE_MIN_AGE
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¶
TIMELINE_CREATE="yes"
TIMELINE_CLEANUP="yes"
TIMELINE_MIN_AGE="1800"
TIMELINE_LIMIT_HOURLY="10"
TIMELINE_LIMIT_DAILY="10"
TIMELINE_LIMIT_MONTHLY="10"
TIMELINE_LIMIT_YEARLY="10"
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.
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:
snapper --config web_data create /srv/www
The configuration file is created under
/etc/snapper/configs/,
where NAME is the value you specified with
NAME-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:
ALLOW_USERS="www_admin"
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:
chmod a+rx /srv/www/.snapshots
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:
www_admin:~ > snapper -c web_data list
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:
TIMELINE_CREATE="no"
Uninstall the package
snapper-zypp-plugin
Edit /etc/sysconfig/yast2 and set
USE_SNAPPER to no:
USE_SNAPPER="no"
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
drop-down menu in YaST or specify the -c on the
command line (snapper -c
MYCONFIG
COMMAND).
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.
Snapper knows three different types of snapshots: pre, post, and single. Physically they do not differ, but Snapper handles them differently.
pre
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.
post
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.
singleStand-alone snapshot. Used e.g. for the automatic hourly snapshots. This is the default type when creating snapshots.
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.
Creating a snapshot is done by running snapper create or by clicking in the YaST module . The following examples explain how to create snapshots from the command line. It should be easy to adopt them when using the YaST interface.
![]() | 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. | |
--description "Snapshot for week 2
2013"
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.
--config home create
--description "Cleanup in ~tux"
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.
--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.
--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.
--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.
--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.
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 module already lists all snapshots. Choose one from the list and click .
--cleanup-algorithm "timeline"
10
Modifies the metadata of snapshot 10 for the default
(root) configuration. The cleanup algorithm is set
to timeline.
--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.
To delete a snapshot with the YaST module, choose a snapshot from the list and click .
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.
![]() | Deleting Snapshot Pairs |
|---|---|
When deleting a | |
Deletes snapshot 65 for the default (root)
configuration.
-c home delete 89 90
Deletes snapshots 89 and 90 for a custom configuration named
home.
![]() | 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.
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.
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.
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 tool to remove users.
/boot and Boot Loader Changes¶
Currently SUSE Linux Enterprise Desktop 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.
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.
/var/log,
/tmp and Other Directories?
For some directories we decided to disable
“snapshotting”, e.g. /var/log since
reverting logs makes searching for problems difficult. To exclude a
path from “snapshotting” we create a subvolume for that
path. The following mount points are excluded from
“snapshotting” on SUSE Linux Enterprise Desktop:
/opt
/srv
/tmp
/var/crash
/var/log
/var/run
/var/spool
/var/tmp
This is currently not possible. The boot loader on SUSE Linux Enterprise Desktop
currently does not support booting from a Btrfs
partition.
Apart from snapshots on Btrfs file systems, snapper
also supports “snapshotting” on thin-provisioned LVM volumes
(snapshots on regular LVM volumes are not supported)
formatted with ext3 or XFS. For more information and setup instructions,
refer to Section “LVM Configuration” (Chapter 12, Advanced Disk Setup, ↑Deployment Guide).
In order 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(. To
date ext3 and XFS are supported, so FILESYSTEM)ext3 or
xfs are valid values for
FILESYSTEM. Example:
snapper -c lvm create-config --fstype="lvm(xfs)" /thin_lvm
You can adjust this configuration according to your needs as described in Section 4.2.3.1, “Adjusting the Config File”. Now you can use Snapper to create and manage snapshots, to restore files, and undo changes as described above.