📸 Btrfs Subvolumes and Snapshots: Instant Rollback for Linux Admins

The most reassuring sentence to type before a risky upgrade is “I can roll this back in two seconds.” On a Btrfs filesystem, that’s literally true. A snapshot is a copy-on-write reference to the current state of a subvolume — it takes a fraction of a second, costs almost no space until things diverge, and lets you boot back into “before the change” if the upgrade goes sideways. I’ve recovered a kernel update that wouldn’t boot by selecting a pre-upgrade snapshot from the bootloader and being back in business before I’d finished my coffee.

But Btrfs is also a footgun if you treat it like ext4 with bonus features. Subvolumes, snapshots, and the flat-vs-nested layout decisions matter, and getting them wrong turns “instant rollback” into “why is my snapshot the same size as my whole disk.” Here’s how I lay out and snapshot Btrfs, and where an AI copilot helps plan a rollback without nuking data I meant to keep.

Subvolumes: the unit of snapshotting

A Btrfs subvolume is an independently snapshottable, mountable subtree of the filesystem. The key insight: you snapshot a subvolume, not a directory. So your layout determines what you can roll back independently.

# See what subvolumes exist
sudo btrfs subvolume list /

# Create a subvolume
sudo btrfs subvolume create /mnt/btrfs/@srv

The common convention (used by openSUSE, and a good idea anywhere) is a flat layout where the root filesystem and other major trees are separate subvolumes named with an @ prefix:

@         -> mounted at /
@home     -> mounted at /home
@var      -> mounted at /var   (or @var/log etc.)
@snapshots-> holds snapshots, kept OUT of the root subvolume

Why separate @home and @var? Because you almost never want to roll those back when you roll back /. If @home lived inside the @ snapshot, restoring a pre-upgrade root would also throw away every file your users created since. Separating them means a root rollback leaves home and data untouched.

Taking a snapshot before a risky change

# Read-only snapshot of the root subvolume, timestamped
sudo btrfs subvolume snapshot -r / /.snapshots/root-pre-upgrade-$(date +%F-%H%M)

# Verify it exists
sudo btrfs subvolume list / | grep pre-upgrade

The -r makes it read-only, which is what you want for a pristine restore point — nothing can accidentally mutate your “known good” state. This costs near-zero space immediately; it only grows as the live filesystem diverges from the snapshot.

Rolling back

This is where care matters. A rollback isn’t “restore files” — it’s swapping which subvolume gets mounted as /. The clean pattern:

# 1. Boot from rescue / another root, or work from the snapshot
# 2. Move the broken root subvolume aside
sudo mv /mnt/btrfs/@ /mnt/btrfs/@-broken

# 3. Create a writable subvolume from your read-only snapshot
sudo btrfs subvolume snapshot /mnt/btrfs/.snapshots/root-pre-upgrade-... /mnt/btrfs/@

# 4. Confirm the default subvolume / fstab points at @, then reboot
sudo btrfs subvolume get-default /mnt/btrfs

Tools like snapper (with snapper rollback) automate this dance and integrate with the bootloader so pre-upgrade snapshots appear as boot entries. On a fresh setup, installing snapper and wiring it to your package manager (e.g. an apt/dnf hook that snapshots before each transaction) is worth the hour.

The Btrfs-specific traps

Things that bite people coming from ext4:

• Snapshots are not backups. They live on the same disk. A failed drive or a mkfs takes the snapshots with it. Snapshots are for fast local rollback; you still need real off-host backups.
• Free space lies. df is famously misleading on Btrfs because of how it allocates. Use btrfs filesystem usage / for the truth. Snapshots holding old data keep that space pinned until deleted.
• Quota groups (qgroups) are expensive. Enabling qgroups for per-subvolume accounting can seriously slow balance and snapshot-delete operations. Don’t enable them unless you need them.
• Deleting snapshots reclaims space asynchronously. Space comes back via background cleanup, not instantly. Don’t panic if usage lags after a delete.

Planning the rollback with AI

The rollback dance — which subvolume to move aside, what fstab and the default subvolume must point at, and crucially what not to roll back — is fiddly and easy to get wrong under the pressure of a broken system. I describe my layout to an AI copilot and have it produce the exact sequence and the guardrails.

Prompt: You are a senior Linux storage engineer. My Btrfs layout: @ -> /, @home -> /home, @var -> /var, snapshots in @snapshots. A kernel upgrade left the system unbootable. I have a read-only snapshot root-pre-upgrade-2026-06-22. Give me the exact rollback sequence from a rescue shell, and explicitly tell me what will and won’t be reverted, and what I should capture before rolling back.

Response (excerpt): Only @ (/) reverts — @home and @var are separate subvolumes and are untouched, which is correct here (you keep user data and logs). Before rolling back, capture the failure evidence from the broken root (journalctl from the failed boot, the new kernel/initramfs versions) by mounting @ read-only, because the rollback won’t delete @ (we rename it to @-broken) but you’ll want that data. Sequence: mount the top-level subvolid 5, mv @ @-broken, btrfs subvolume snapshot @snapshots/root-pre-upgrade-2026-06-22 @, verify btrfs subvolume get-default and fstab reference @, then reboot. Do NOT delete @-broken until the restored system boots and you’ve extracted the logs.

That’s the model doing what it’s good at: laying out the precise, order-sensitive steps and — most valuably — telling me exactly what won’t revert (home and var, by design) and to preserve the broken root for forensics before reboot. I read the plan, confirmed my fstab actually used @, and kept @-broken around. AI drafts the rollback choreography; the human verifies the layout assumptions and keeps the escape hatch open.

The takeaway

Btrfs turns “roll back the risky change” from an hour of restore into a two-second snapshot and a subvolume swap — but only if you lay out subvolumes so that rolling back / doesn’t drag /home and /var with it. Treat snapshots as fast local rollback, never as backups (they share the disk), watch the Btrfs-specific traps around free space and qgroups, and let snapper automate the bootloader integration. AI is a strong partner for planning the order-sensitive rollback dance and spelling out what will and won’t revert, but the model works from your stated layout — so you confirm fstab and the default subvolume yourself, preserve the broken state for forensics, and only delete the old subvolume once the restored system is genuinely back. Snapshot freely; roll back deliberately.

For the wider filesystem picture, see choosing a Linux filesystem and Linux backup and restore done right for the off-host layer snapshots can’t replace. The Btrfs balance and snapshot management prompt is a good companion for ongoing maintenance.