snapper: filesystem snapshots that let a system change be undone

Reverting, not just snapshotting

The README opens with a plain description of a tool for Linux file system snapshot management, and then says what makes it more than that. Apart from the obvious creation and deletion of snapshots it can compare snapshots and revert differences between them.

That single capability is the project. In simple terms, the README puts it, this allows root and non-root users to view older versions of files and revert changes.

Most snapshot mechanisms answer the question of what changed. Snapper's snapshot-plus-diff-plus-revert answers what to do about it. The difference matters for the case the tool is actually built for: a user who ran a package upgrade or a script and broke their system, who then needs a way back without an administrator intervening.

The pairing of diff and revert is also what makes the non-root part work. A snapshot system that only creates snapshots still needs privileged access to restore from one, because restoring writes to the filesystem. If the diff and revert happen inside a service that holds the privilege and the client merely requests them, the privilege boundary is a design decision rather than an accident.

The audience is therefore two-sided. Distributions embed it so users get an undo button, and administrators use it as a safety net before risky operations.

A D-Bus service that the CLI talks to

The repository layout shows the client and server split, and the run instructions make the architecture concrete.

The top level has client/, server/, dbus/, snapper/ and stomp/ directories, along with pam/, zypp-plugin/, scripts/, data/, doc/, package/, dists/, po/ and examples/. There is also a separate testsuite/, testsuite-real/ and testsuite-cmp/.

The build and install sequence makes the process boundary visible.

git clone [email protected]:<your_fork>/snapper.git
cd snapper
make -f Makefile.repo
make -j`nproc`

Makefile.repo is the entry point for building from a repository checkout, and the parallel build uses nproc, with a note to use plain make if it does not work.

Then installation and first run.

sudo make install
sudo killall snapperd
(sudo) snapper ...

The killall snapperd line is the important one. The comment says to kill the currently running DBus process if present, and the next comment says the DBus service is started automatically. So snapperd is a long-lived service that the client talks to over D-Bus, and after replacing the binaries you have to clear the old one out of the way.

The (sudo) in the last line is also telling. Snapper can be used with or without root, and the design supports the unprivileged case as much as the privileged one. That is the whole point of the revert feature being available to ordinary users.

Distribution packaging, a zypp plugin and PAM

The repository contains more than a snapshot daemon, and the extra directories tell you who the project is really for.

There is a zypp-plugin/ directory, which points at integration with the zypper package manager on SUSE systems.

There is a pam/ directory, meaning Snapper is integrated with the PAM authentication stack.

There are also language bindings in the examples/ directory, with c++-lib/, c/, python/, qt/ and ruby/ subdirectories, each with a Makefile.am. A C++ core with bindings for other languages is a sensible shape for a daemon that has to be callable from a desktop application.

The dists/ and package/ directories, the snapper.spec.in file, the po/ directory for translations, and the stomp/ directory all point the same way. This is infrastructure that a distribution ships, not a library a developer vendors.

Building dependencies differ sharply between SUSE and RHEL

The development environment section gives two separate dependency sets, and the difference between them is instructive.

On SUSE Linux Enterprise and openSUSE, the pattern-based approach is used.

sudo zypper install -t pattern SDK-C-C++
sudo zypper install -t pattern devel_C_C++

The SLE line notes that the SDK extension is needed, which is the SUSE mechanism for a full development toolchain.

Then the extra packages, which are the same on both distributions.

sudo zypper install git libmount-devel dbus-1-devel libacl-devel libboost_thread-devel libjson-c-devel \
  docbook-xsl-stylesheets libxml2-devel libbtrfs-devel libopenssl-devel

On RHEL-based distributions the equivalent uses a group install and a longer explicit list.

sudo dnf groupinstall "Development Tools"
sudo dnf install git libmount-devel dbus-devel libacl-devel \
    docbook-xsl libxml2-devel btrfs-progs-devel \
    cmake make automake gcc-c++ systemd-devel boost-devel \
    ncurses-devel json-c-devel pam-devel openssl-devel

The libraries tell you what Snapper actually depends on at runtime. libmount is how it finds and mounts filesystems, libbtrfs is the Btrfs binding, which tells you the primary snapshot backend, libacl is for POSIX access control on snapshot directories, dbus is the service bus, libboost_thread for threading, libjson-c for the DBus method signatures, docbook-xsl and libxml2 for the manual pages, and pam-devel for the PAM module. The PAM dependency appears only in the RHEL list because the SUSE pattern already provides it.

If you are building on a distribution not covered here, the dependency set is the specification: libmount, dbus, libacl, btrfs, Boost threads, json-c, PAM and OpenSSL.

The tests that destroy your data are labelled as such

The Running Tests section is short and the warning is emphatic.

Snapper includes some internal unit tests to avoid some bugs and regressions. The tests are located in the testsuite subdirectory and you can start them using the make check command.

Then there is the other one. There are also some additional tests in the testsuite-real subdirectory, but be careful. These tests really execute snapper commands and they can destroy your data! Run these tests only in a testing environment!

That is a good practice that more projects would copy. A test suite that shells out to the real daemon against the real filesystem is the only way to test snapshot and revert behaviour, because the behaviour is inseparable from the filesystem, but it also means the suite is destructive by design. The presence of testsuite-cmp/ as a third directory suggests comparison tests between implementations or configurations, and the naming convention of the three directories makes the risk legible before you run anything.

The post install steps are small but easy to miss.

sudo mkdir -p /etc/sysconfig
sudo touch /etc/sysconfig/snapper
sudo chmod 644 /etc/sysconfig/snapper
sudo restorecon -v /etc/sysconfig/snapper # if SELinux

The restorecon line is conditional on SELinux, and it is there because an empty config file created with a plain touch gets the wrong security context. A tool that manages system state will trip over an SELinux denial, and this is the kind of detail that costs an afternoon if you do not know to look for it.

Releasing means updating four places at once

The Releasing section is unusually detailed, and it describes a project where the source of truth is spread across several systems.

Before releasing the Snapper package you have to ensure that the changes made to the package are mentioned in the package/snapper.changes file, and update also the dists/debian/changelog file. The unit tests still have to pass.

When the version is increased, the Git repo has to be tagged, using the vX.Y.Z format for the tag, and the filesystems:snapper OBS project has to be updated.

Then the package is created with make package and submitted to the build service through the common workflow, with the note that for openSUSE:Factory you send the package at first to the devel project filesystems:snapper in OBS. The README also flags that this OBS project builds for more distributions, so more metadata files have to be updated, with links to the cross distribution howto and the Debian builds documentation.

The generated xz tarball has to be placed at the ftp.suse.com projects directory, and when the documentation changes, such as the man page or an important functionality, the snapper.io web pages have to be updated too. Those pages are hosted as GitHub pages in the gh-pages branch of the Snapper Git repository.

The four places to update are therefore the package changelog, the Debian changelog, the git tag and the OBS project, with the documentation site as a fifth when the manual changes. The VERSION and LIBVERSION files at the root are the version sources.

That is a lot of manual coordination, and it is the cost of a project that ships across distributions and a vendor's own channels.

A mature tool with a current release line

The release history shows v0.13.2 on 2026-09-07, v0.13.1 on 2026-04-22 and v0.13.0 on 2025-09-09, and the last push was on 2026-10-15, so the tree is being worked on.

The 0.x version number and the length of the release history suggest a tool that has shipped for a long time rather than something new.

The maintenance cadence is worth noting. The releases sit a few months apart, which is a slower and steadier rhythm than a web project, and it fits a tool that ships through distribution channels rather than straight from a package registry. openSUSE and SUSE Linux Enterprise are the primary targets given the zypper integration and the OBS workflow, but the RHEL development instructions and the Debian packaging in dists/ show the project is built with more than one distribution in mind.

The licence is GPL-2.0, with the COPYING file at the root, and the project is under the openSUSE organisation on GitHub. The homepage is snapper.io, and the AUTHORS file at the root records the contributors.

For an adopter, the practical picture is a tool that is deeply integrated with a Linux distribution's package management and login stack, with a D-Bus service and a privilege boundary designed so that undo is available to ordinary users. That integration is the feature, and it is also what ties the project to the distributions that ship it.

Editorial conclusion

snapper suits a Linux administrator or a distribution that wants users to be able to undo a change without root, since the revert capability is the part that distinguishes it from a plain snapshot script and the D-Bus service lets unprivileged clients drive it. It is the wrong tool if you need snapshots on a filesystem with no snapshot support of its own, since the underlying mechanism is the filesystem's, and it is the wrong choice on a system where you want the undo path to be unavailable to ordinary users, since granting that is a deliberate policy decision. Before you adopt it, read the testsuite-real warning, because those tests really execute snapper commands and can destroy your data, and note the release process requires the package changelog, the Debian changelog and the OBS project to be updated together.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. openSUSE/snapper on GitHub
3. Project website
4. README
5. Releases