btrfs Snapshots Saved My Weekend

01What a Snapshot Actually Is

A lot of people treat btrfs snapshots like a magic undo button and never bother learning why they work. That's fine until something goes wrong in an unexpected way and the magic stops. Spend five minutes understanding the mechanism and you'll never be caught out.

Roll back a broken update in one reboot.

btrfs is a copy-on-write filesystem. When you write a new version of a file, btrfs doesn't overwrite the old blocks — it writes the new data elsewhere and updates a pointer. A snapshot exploits this: it's a subvolume that shares the same underlying blocks as the original, frozen at the moment you took it. Because blocks are shared rather than duplicated, a fresh snapshot costs almost nothing in disk space. Only the blocks that subsequently change consume extra space, and only for as long as both the snapshot and the modified file coexist. Delete the snapshot, those blocks are reclaimed.

The practical upshot is that you can snapshot an entire root filesystem in milliseconds, reboot into it if an update destroys your desktop environment, confirm everything is fine, and delete the broken state. No backup drive required, no thirty-minute restore process.

02Setting Up Snapper Before You Need It

The canonical tool for managing btrfs snapshots on Linux is Snapper, developed at SUSE and now available in virtually every major distribution's repositories. Paired with a small GRUB integration package, it makes rollbacks available directly from the boot menu — which is exactly where you want them when your display manager won't start.

Install the pieces. On Fedora or any dnf-based system:

sudo dnf install snapper python3-dnf-plugin-snapper grub2-btrfs

On Debian, Ubuntu or their derivatives:

sudo apt install snapper snapper-gui grub-btrfs

On Arch:

sudo pacman -S snapper snap-pac grub-btrfs

grub-btrfs is the package that regenerates your GRUB menu to include bootable snapshot entries. Without it, snapshots exist but you can't boot into them from a menu — you'd have to mount them manually from a live USB.

Create a Snapper configuration for root. Snapper works against a specific subvolume. Your root subvolume is almost always mounted at /, so:

sudo snapper -c root create-config /

This writes /etc/snapper/configs/root with sensible defaults. Check it with cat and you'll see timeline settings, cleanup policies and retention numbers you can tune later.

Enable the timeline. Snapper can take automatic hourly snapshots and clean up old ones on a schedule. Enable the two relevant systemd timers:

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

Now take a manual snapshot to confirm everything is wired up:

sudo snapper -c root create --description "before-anything-breaks"
sudo snapper -c root list

You should see your snapshot in the list with a number, timestamp, and description.

Wire up GRUB. Regenerate the GRUB configuration so existing and future snapshots appear as boot entries:

sudo grub-mkconfig -o /boot/grub/grub.cfg

Enable the grub-btrfs path-watch service so the menu stays current automatically:

sudo systemctl enable --now grub-btrfsd

Reboot. In the GRUB menu you should see an Arch Linux snapshots or Fedora Linux snapshots submenu (naming varies by distro) listing your bootable snapshot entries.

03The Actual Rollback

When an update wrecks something — a kernel module that kills Wi-Fi, a graphics driver regression that drops you to a blank screen, a wayward package that half-removes a dependency — the process is straightforward.

Reboot into your most recent pre-update snapshot from the GRUB submenu. The system comes up in read-only mode from the snapshot, but it's fully functional. Verify that the problem is gone. Then, to make the rollback permanent:

sudo snapper -c root rollback

Snapper creates a new writable subvolume from the snapshot, sets it as the default boot subvolume, and moves the broken state to a numbered snapshot you can inspect or delete. Reboot once more into normal operation. You're back where you were before the update, and the broken state sits safely on disk until you tidy up with snapper delete.

04A Few Things to Know

One thing btrfs snapshots do not protect is a separate /home subvolume — and most distributions that use btrfs will put /home on its own subvolume precisely so rollbacks don't affect user data. That's the correct behaviour: rolling back the system shouldn't clobber files you created after the snapshot. Configure a separate Snapper configuration for /home if you want point-in-time protection there too.

Snapshots also don't replace off-site or offline backups. If a drive dies, every snapshot on it dies with it. Think of snapshots as your fast, low-friction recovery layer for software mistakes — a complement to full-disk encryption and real backups, not a substitute for either.

Disk space is worth watching. snapper list and btrfs filesystem usage / are your friends. Most default Snapper configurations keep a sensible number of hourly, daily and monthly snapshots, but on a small drive you'll want to tighten the NUMBER_LIMIT values in the config.

Set this up once, on a quiet afternoon, and you'll never spend a weekend coaxing a broken update back to life again.