Btrfs Snapshots with Snapper: Recover Your System and Data on Linux

Btrfs has established itself in recent years as one of the most advanced and flexible file systems in the ecosystem. Linux. Its ability to create efficient snapshots and its self-management features have made it a favorite choice for distributions such as openSUSE, Siduction, and Arch Linux. However, its potential is multiplied when combined with Snapper, a specialized tool for managing snapshots, restoring, and automating backup tasks in real time.

This article aims to thoroughly and practically break down how snapshots work in Btrfs and how to get the most out of them with Snapper. We will cover everything from fundamental concepts to advanced configurations, recovery examples, automation, tips, Tricks and performance recommendations. All in Spanish and with familiar vocabulary, illustrating both the benefits and potential pitfalls you may encounter when deploying this solution on your Linux system or server.

What is Btrfs and why does it matter for snapshots?

Btrfs, short for B-Tree File System, is a modern file system that introduces copy-on-write (CoW) philosophy to data management on Linux. The main attraction for advanced users and administrators lies in its ability to create subvolumes and snapshots almost instantly and with minimal space usage.

Unlike more traditional file systems like ext4, Btrfs implements:

• Subvolumes: Directories that behave like internal logical partitions, allowing specific areas of the file system to be isolated and managed independently.
• Snapshots: Point-in-time copies of a subvolume, which, thanks to CoW, only take up space when files are modified relative to the original. This makes them ideal for Recover previous system states, perform efficient backups, or protect against update errors.

The Btrfs structure allows each subvolume to have its own file hierarchy and configuration, appearing to the user as normal directories but with special internal management.

Why is Snapper the perfect companion for Btrfs?

Snapper is the star tool for getting the most out of Btrfs snapshots. Not only does it allow you to create and delete snapshots, but it also automates snapshot taking at critical times (such as system updates), compares differences between states, and facilitates both individual file and system-wide restoration. It also supports automatic timelines and scheduled cleanups to avoid filling up the disk.

Among the reasons why Snapper is almost essential if you use Btrfs are:

• Automating snapshots at key events (package installation, updates, administrative changes…)
• Ability to compare and undo changes between two points in There. Ideal for finding out what's broken after an update, or what files have been accidentally touched.
• Granular restoration, both at the level of a specific file and of the entire operating system in the event of a disaster.
• Support for automatic cleaning depending on space limits, age or number of snapshots.
• CLI interface and graphical modules (for example, yast2-snapper or btrfs-assistant for users who prefer not to deal with commands).

Fundamental concepts: subvolumes and snapshots in Btrfs

To fully understand how Snapper manages snapshots, it is worth first clarifying how Btrfs organizes its internal hierarchy.

Subvolume in Btrfs

A subvolume is a type of logical partition within Btrfs. It appears as a normal directory, but can be mounted independently, has its own namespace, and is managed separately at the snapshot and quota levels.

By default, many distros (openSUSE, Siduction, Arch…) set up subvolumes as:

• @ to root 🇧🇷
• @home to / Home
• @snapshots for the folder /.snapshots
• @var_log to / var / log

Thanks to this you can take snapshots only of the system, leaving user data or logs out if you prefer. When recovering, for example, your operating system after a failed update, you can leave your personal files intact and just restore the root.

What is a snapshot in Btrfs?

In the context of Btrfs, a snapshot is a special subvolume that stores the exact state of another subvolume at a specific point in time. However, thanks to the CoW model, it only takes up space as files change relative to the original.

This means you can have dozens of historical snapshots taking up only a fraction of the total space, and restore any of them almost instantly.

Snapshots are not recursive: they only capture the contents of that subvolume, not any nested subvolumes. That's why it's important to structure your subvolume layout well to isolate critical data that you never want to lose (for example, your personal folders or system logs).

Snapshot Types: When and How Are They Created?

Snapper allows you to distinguish between several types of snapshots, although internally for Btrfs, they are all technically identical. Snapper imposes the differences for management, comparison, and cleanup purposes:

• Pre: Snapshot taken before a major change (for example, before installing major updates).
• Post: Snapshot immediately after the same change. This way you can easily compare what's changed.
• Single: Manual snapshots, automatic timeline snapshots, or any other snapshots not associated with a specific pre/post event.

Most distributions that integrate Snapper enable automatic pre/post snapshot creation by default for administration actions or package installations. For example, openSUSE creates snapshots before and after each update with YaST. Siduction does the same for each APT operation. This way, you can always revert to a previous state if something goes wrong.

Timeline Snapshots

Another key feature is the automatic snapshot timeline. You can configure Snapper to create snapshots every hour, day, week, month, or year, always keeping only the specified number of snapshots and deleting older ones based on cleanup rules.

By default, it is usually enabled on systems with sufficient free space, and you can easily adjust it in the corresponding configuration file.

How to install and configure Snapper on your Btrfs system

Installation varies slightly depending on your distribution, but on most RPM-based systems (openSUSE, RHEL, Siduction, Fedora, etc.) it's as simple as running:

• openSUSE/SLE: zypper install snapper (optionally yast2-snapper and snapper-zypp-plugin for full integration).
• Arch Linux / Manjaro: pacman -S snapper and, for graphical interface, yay -S btrfs-assistant snapper-gui-git
• Debian/siduction: apt install snapper

Once installed, the next step is to create the configuration for the subvolume or partition you want to protect. Typically, for the root system:

# snapper -c root create-config /

This performs several automatic actions:

• Create the configuration file for Snapper in /etc/snapper/configs/root.
• Prepare the folder /.snapshots within the corresponding subvolume to store the snapshots.
• Update the variable SNAPPER_CONFIGS in the global settings file.

If you want to manage / Home (or any other subvolume), just repeat the process:

# snapper -c home create-config /home

Remember that having a proper subvolume structure is critical to protecting only what you care about—if you're only interested in protecting the system, isolate user and data folders on separate subvolumes to avoid accidentally reverting them during a rollback.

Main parameters and configuration editing

The magic of Snapper is in its configuration files, located in /etc/snapper/configs/Some key settings you can customize to your needs and available space:

• TIMELINE_CREATE: “Yes” or “No”. Enables or disables the automatic snapshot timeline.
• TIMELINE_LIMIT_HOURLY/DAILY/WEEKLY/MONTHLY/YEARLY: Maximum number of snapshots to keep of each type.
• NUMBER_CLEANUP, NUMBER_LIMIT, NUMBER_MIN_AGE: They control the cleaning of manual or numbered snapshots.
• FREE_LIMIT and SPACE_LIMIT: Defines the minimum free space and maximum space reserved for snapshots.
• ALLOW_USERS and ALLOW_GROUPS: List of users or groups that can manage snapshots for that configuration.
• SYNC_ACL: If "yes", Snapper automatically synchronizes the directory ACL permissions .snapshots according to the allowed users/groups.

For quick boundary changes or toggling the timeline on/off, you can edit the file directly or use the command:

# snapper -c root set-config TIMELINE_CREATE=yes NUMBER_LIMIT=20

By the way, on most modern systems snapshot cleanup is managed by systemd via timers (snapper-timeline.timer y snapper-cleanup.timer), although on older systems you can still use cron.

How snapshots are stored and accessed

Each snapshot that Snapper takes is actually a child subvolume within the folder /.snapshots of the corresponding subvolume. For example, snapshots of the root system will be in /.snapshots/X/snapshot/, where X is the snapshot number.

You can browse them as read-only directories. If you need to recover a specific file, simply copy it from the appropriate snapshot to its original location.

# cp /.snapshots/16/snapshot/etc/hosts /etc/hosts

If you need to modify the snapshot (not recommended except in special cases), you can temporarily reconfigure the snapshot subvolume as writable using:

# btrfs property set /.snapshots/ /snapshot ro false

Make sure to return it to read-only after modification to avoid inconsistencies.

Snapshot creation and management: manual, automatic, and event-based

Manual snapshots

You can create a snapshot at any time with:

# snapper -c root create --description "my manual snapshot" --cleanup-algorithm number

Eye! If you do not specify the cleaning algorithm (--cleanup-algorithm), the snapshot will remain indefinitely until you delete it manually, which can fill up the disk if abused.

Automatic timeline snapshots

When the timeline feature is enabled, Snapper creates snapshots periodically (e.g., hourly, daily, weekly, etc.). The limits and frequency are controlled in the settings (TIMELINE_LIMIT_*).

The frequency is controlled by systemd timers (see How to modify the boot menu timeout). You can edit the timers to increase or decrease frequency by changing the field OnCalendar.

Pre/post snapshots and transaction wrapping

Snapper is able to wrap any important action (such as a package update) with a before and after snapshot. This way you can always compare what's changed and revert if something goes wrong.

For example, in openSUSE and SUSE this is automatically integrated when using YaST or Zypper. In Arch Linux there are packages like snap-pac, grub-btrfs or tools like refind-btrfs to add this functionality.

In APT-based systems, such as siduction, apt actions can wrap operations in pre/post snapshots (thanks to the default integration).

Restore and rollback: how to recover your system or a file to a previous state

Restore a specific file or folder

If you only want to undo changes to a specific file, you can use Snapper to compare and restore it:

# snapper status 42..45 /etc/hosts

This will show you what has changed between snapshots 42 and 45. If you decide to restore the file:

# snapper diff 42..45 /etc/hosts

# snapper undochange 42..45 /etc/hosts

The command undochange reverts only that file, without affecting the rest of the system. If you need to visually compare files, programs like Report can help you visualize and select only the changes that interest you.

Restore the entire system root to a previous snapshot (rollback)

In the event of a total disaster following a problematic update or an action that has left the system unstable, you can completely undo the system state with the rollback feature.

The general procedure is:

1. Reboot the system and access the menu Boot to boot from the desired snapshot (tools like Dual boot Windows and Linux make it much easier).
2. Verify that the system boots correctly in read-only mode. If everything is correct, start the full restore:

   # snapper --ambit classic rollback

3. Snapper will create a new backup snapshot, copy the desired state to a new subvolume, and set it as the new default.
4. Reboot the system: It will boot directly into the reverted state.

Important! If you use a subvolume structure (for example, @home separately), only the system will be restored, your personal files will remain intact.

Bootloader integration and snapshots as a boot option

Tools like grub-btrfs They allow each Snapper snapshot to appear as an entry in GRUB, making it easy to boot from any previous system state quickly and easily. This way, if the system stops working after an update, you can directly select the previous snapshot from the bootloader.

For this to work, the snapshots must be mounted as subvolumes and the directory /.snapshots must be readable. Some services require the snapshot to be mounted as writable, or to use overlayfs to simulate a writable environment without modifying the base snapshot (ideal for temporary recovery or diagnostics).

Managing permissions and access by non-root users

By default, only the superuser has the right to create, delete, or list snapshots. If you want other users to be able to manage snapshots of certain configurations, add their names to ALLOW_USERS or their groups to ALLOW_GROUPS in the corresponding configuration file.

Make sure to adjust the directory permissions /.snapshots to give the user/group at least read and execute (e.g. change the owning group to “users”).

Recommendations for layout and subvolume structure

Logical planning of subvolumes and mount points is key to managing snapshots efficiently and restoring only what is needed when needed.

A typical recommended scheme might be:

Subvolume	Mounting point
@	/
@home	/ Home
@snapshots	/.snapshots
@var_log	/ var / log

This allows you to restore the system without affecting user data or logs, and keeps snapshots off the main subvolume to avoid circular dependencies. It is recommended to have /.snapshots as a separate mounted subvolume, not just a directory.

Snapshot algorithms and cleanup: avoiding disk fill

The weakness of automatic snapshot systems is the gradual filling of disks if left unchecked. Snapper includes several options for cleaning up old snapshots based on predefined rules:

• Quantity limits (NUMBER_LIMIT for pre/post and manual snapshots).
• Age limits (NUMBER_MIN_AGE).
• Timeline limits (TIMELINE_LIMIT_HOURLY, TIMELINE_LIMIT_DAILY...).
• Maximum occupied space (SPACE_LIMIT).
• Minimum free disk percentage (FREE_LIMIT).

The cleanup system runs by default daily using systemd (How to update UEFI firmware settings from Linux), but you can manually adjust or force it at any time. The current snapshot is never automatically deleted.