Btrfs Snapshots on Fedora Workstation: Rollbacks, Subvolumes, and the Upgrade Safety Net

You’ve just started a dnf system-upgrade and the screen goes black. On Fedora Workstation since Fedora 33, the default filesystem is Btrfs, which gives you a built-in, low-overhead way to roll back—but only if you understand the subvolume layout and when a snapshot actually protects you. The useful takeaway: taking a Btrfs snapshot before a major upgrade gives you a concrete recovery path via the GRUB menu, but snapshots live on the same device and don’t replace a separate backup.

The default Btrfs layout on Fedora Workstation

Fedora’s installer creates a Btrfs setup with two primary subvolumes: one mounted at / (root) and another at /home. This separation matters when you snapshot. A snapshot of the root subvolume captures the system files, kernel, and installed packages, but it does not include the files living in /home. If you only snapshot /, a rollback restores your system to a previous state, but your user documents, configs, and browser data remain at whatever state they were at snapshot time. The reverse is also true: snapshot /home and you preserve user data, but the system files revert to whatever the system partition holds. Understanding which subvolume you’re working with is the first step to a safe rollback workflow.

Taking a snapshot before a risky operation

Before running dnf system-upgrade or a major dnf distro-sync, you can create a snapshot of the root subvolume. The command is run in a terminal with root privileges:

sudo btrfs subvolume snapshot / /.snapshots/pre-upgrade-$(date +%Y%m%d)

Where to run it: any Fedora Workstation terminal with sudo access.
Required permissions: root (or su -).
Meaningful placeholder: replace /.snapshots/pre-upgrade-YYYYMMDD with a path you prefer; the leading / ensures it’s created at the filesystem root.
Expected check: after running the command, btrfs subvolume list / will show the new entry under the root subvolume.
Relevant risk: if the underlying Btrfs device fails, the snapshot is lost along with the original data—this is why snapshots are not backups.

Rollback reality: snapshots, compression, and limits

If an upgrade leaves the system unbootable, the GRUB menu on Fedora typically lists the most recent kernel alongside older ones. A Btrfs snapshot doesn’t automatically appear in GRUB, but you can use it to revert the system partition before the next boot. To do this, boot from a Fedora live USB, mount the root subvolume, and use btrfs subvolume delete / followed by btrfs subvolume snapshot <snapshot-path> / to restore the system state. Alternatively, many Fedora users rely on the snapper tool, which integrates with systemd and can create pre- and post-upgrade snapshots that the bootloader can utilize.

Transparent compression, often zstd, is enabled on Fedora’s Btrfs setup. You can verify it with btrfs filesystem show /; compression settings appear in the output. Compression can reduce disk usage and, on modern CPUs, improve read performance for workloads with small random reads—but effects are workload-dependent, and compressing already-compressed data (like encrypted archives) may actually increase size.

A critical limitation: btrfs check --repair is widely considered risky for severe corruption. If metadata damage is detected, the safest path is restoring from a known-good backup, not attempting in-place repair. Additionally, snapshots exist on the same physical device; a disk failure takes out both the live system and every snapshot. A separate backup mechanism—such as timeshift configured for Btrfs, rsync to an external drive, or a cloud sync—remains essential.

An actionable check without risking your primary machine

If you’re running Fedora Workstation and haven’t looked at your Btrfs layout recently, open a terminal and run btrfs subvolume list /. Note the subvolume IDs and paths for root and home. Before your next major upgrade, create a snapshot of the root subvolume, note its name, and reboot to verify the GRUB menu reflects your current kernel. If you want to test the rollback path, spin up a Fedora VM, take a pre-upgrade snapshot, run dnf system-upgrade, and confirm you can select the snapshot or an older kernel from the boot menu. That hands-on test is the most reliable way to know your rollback strategy works—without putting your primary workstation at risk.