How to Use Snapper on Btrfs: Automatic Snapshots and Linux Rollback on Failed Updates – ITFROMZERO

Table of Contents

When an `apt upgrade` Crashes a Production Server

Early in my career, I spent an entire afternoon recovering a web server cluster. The reason was embarrassingly simple: running apt upgrade on production without prior testing. A new kernel update conflicted with the network driver, causing the server to lose its IP address. With SSH access broken, I had to plug into a rescue KVM console and spent four nerve-racking hours fixing it.

That incident taught me a critical lesson: every production change must have an easy rollback plan. If your server uses the Btrfs filesystem, Snapper is the ultimate lifesaver. This tool automatically captures system states before and after installing packages. If anything breaks, you can turn back the clock with a single rollback command.

Understanding Btrfs Subvolumes and the Snapshot Mechanism

To operate Snapper effectively, you only need to understand two foundational concepts:

1. Btrfs Subvolumes and Copy-on-Write (CoW)

Btrfs divides a disk into independent subvolumes that share the total storage pool. Thanks to Copy-on-Write (CoW), a newly created snapshot takes up exactly 0 MB of actual disk space. Storage is only consumed when data is added or overwritten. You can keep 50 snapshots without worrying about immediately running out of space.

2. Three Types of Snapper Snapshots

Snapper categorizes snapshots clearly based on their intended use:

Single: An independent snapshot at a specific point in time, typically used for scheduled daily backups.
Pre: Created automatically right before running a software installation or update command.
Post: Created right after the installation completes. Snapper pairs Pre and Post snapshots so you can inspect the exact diff of every changed file.

Hands-on: Installation, Configuration, and Rollback Testing

Step 1: Install Snapper and Supporting Tools

On Debian/Ubuntu (requires the root partition to run on a Btrfs @ subvolume layout):

sudo apt update
sudo apt install snapper inotify-tools grub-btrfs

On Fedora, CentOS Stream, or RHEL derivatives (using DNF):

sudo dnf install snapper python3-dnf-plugin-snapper

This DNF plugin is extremely handy. Every time you run dnf update, it automatically generates a Pre/Post snapshot pair.

Step 2: Create a Management Configuration for the Root Partition

Initialize a Snapper configuration for the root directory /:

sudo snapper -c root create-config /

By default, Snapper creates a /.snapshots subvolume. Adjust the cleanup policy to prevent older snapshots from consuming all available disk space:

sudo nano /etc/snapper/configs/root

Configure a reasonable retention policy for typical servers:

# Keep snapshots for at least 30 minutes before cleanup
TIMELINE_MIN_AGE="1800"

# Snapshot retention limits over time intervals
TIMELINE_LIMIT_HOURLY="6"
TIMELINE_LIMIT_DAILY="7"
TIMELINE_LIMIT_WEEKLY="2"
TIMELINE_LIMIT_MONTHLY="0"
TIMELINE_LIMIT_YEARLY="0"

# Automatically clean up based on disk usage quotas
EMPTY_PRE_POST_CLEANUP="yes"
NUMBER_CLEANUP="yes"

Enable the systemd timers to automate snapshot timeline maintenance and cleanup:

sudo systemctl enable --now snapper-timeline.timer snapper-cleanup.timer

Step 3: Create Manual Snapshots and Compare Changes

Before editing critical Nginx or database configuration files, manually create a restore point:

sudo snapper -c root create --description "Before editing Nginx config"

List all available snapshots:

sudo snapper -c root list

Terminal output:

 # | Type   | Pre # | Date                     | User | Cleanup  | Description
---+--------+-------+--------------------------+------+----------+-----------------------------
 0 | single |       |                          | root |          | current
 1 | single |       | Thu 02 Oct 2026 09:00:00 | root | timeline | timeline
 2 | single |       | Thu 02 Oct 2026 10:15:30 | root |          | Before editing Nginx config

Suppose you modified a configuration file and the service now fails to start. Check which files changed between snapshot #2 and the current system state (#0):

sudo snapper -c root status 2..0

Status flag legend:

+: Newly created file.
-: Deleted file.
c: Modified file content.

View line-by-line diffs in a specific configuration file:

sudo snapper -c root diff 2..0 /etc/nginx/nginx.conf

Step 4: Roll Back and Restore the System

If the issue is limited to a few configuration files under /etc, quickly revert changes with:

sudo snapper -c root undochange 2..0

Snapper will immediately restore all modified files to match snapshot #2.

For critical failures such as kernel panics or broken glibc packages following an update, roll back the entire root subvolume:

sudo snapper rollback 2
sudo reboot

The rollback process finishes in under 30 seconds. The machine reboots directly into the stable state captured in snapshot #2 as if the issue never happened.

Conclusion

Btrfs and Snapper are an indispensable pairing for managing Linux environments. They turn risky maintenance operations into safe, controlled procedures. With a well-tuned cleanup configuration, you get a lightweight, self-healing foundation that requires minimal overhead.

When an apt upgrade Crashes a Production Server