Snapper

Snapper is a command-line program capable of managing filesystem snapshots. It has provisions for root and non-root users to review older versions of files and restore them. It also has the ability to create, delete, compare, and undo changes between snapshots. Snapper never modifies the content of snapshots. Thus it will create read-only snapshots (if supported by the system's kernel). Supported filesystems are btrfs and ext4 as well as snapshots of LVM volumes with thin-provisioning. Some filesystems might not be supported depending on the installation. Snapper was initially developed by SUSE Linux but is now in use across many Linux distributions.

Emerge
After USE flags have been set, snapper:

Configuration
Configuration files for are found in the  directory. According to snapper's man page, each filesystem or subvolume that should be snapshotted by snapper requires a configuration file.

A sub-command exists to aid in configuration file generation:

To create a configuration for the root filesystem, run:

This presumes the root filesystem has been formatted with btrfs or some other snapper compatible filesystem. The command will attempt to guess the underlying filesystem type. If the filesystem type is known (in this case btrfs), then it can be specified using the  option. See the man page for more information.

Rollback
Snapper has function called 'rollback' to switch the current mounted btrfs subvolume to an older subvolume. This feature requires a btrfs file system.

To work properly the rollback feature needs an entry in the fstab to mount the subvolume to the directory. If the subvolume is not mounted,  will fail to create a subvolume after the first rollback and give an input/output error. It will also fail to find any snapshot after the first rollback.

For this example, presume that contains the btrfs filesystem snapper will manage. Add the following to :

When snapper is initialized, this fstab entry is not needed, because the subvolume is created in the root subvolume and from there accessible. After the first rollback to a snapshot subvolume (e.g. ), and upon a reboot into the snapshot subvolume the root subvolume will be left. In the snapshot subvolume, the directory is empty (e.g ). Snapper cannot find older snapshots or create new ones in the empty directory.

This seems to be a tradeoff between ease of configuration and possible errors in this configuration. It might be a good setup for a Suse system but the btrfs devs propose another setup. With this flat hierarchy the original subvolume can even be deleted and if need be replaced by one of the snapshots. On the other hand the subvolume has to be mounted manually inside. This mount point has to be and needs to be on the same volume. This is always the case in the way snapper works by default, so you cannot mix it up. Subvolumes can also be moved like regular folders, so you lose nothing when you start with the default way snapper works and change it later on.

Portage
You can have all installations by portage automatically snapshotted with the following configuration:

dbus not running
If seeing dbus error messages such as the following:

terminate called after throwing an instance of 'DBus::FatalException' what: dbus fatal exception Aborted

or

Failure (dbus fatal exception).

dbus is probably not running. To start dbus, on OpenRC, issue:

Furthermore, if dbus refuses to start, check that lvm is running: