LifeBytes Journal

By the end of this guide the reader will be able to identify a Btrfs‑based Fedora installation, boot from a live USB, list and restore snapshots using the graphical utilities btrfs‑assistant and snapper, and verify that the system returns to a functional state without resorting to the command line.

Understanding the Btrfs Layout Used by Fedora

Fedora Workstation and Fedora KDE install the root filesystem as a single Btrfs partition that contains two default sub‑volumes. One sub‑volume holds the traditional “/” hierarchy, while the second is dedicated to /var/lib/machines. The latter exists to keep container images out of snapshot operations; it remains empty on systems that do not run virtual machines. Because Btrfs stores data in sub‑volumes rather than separate partitions, a snapshot captures the state of an entire sub‑volume at a point in time.

The installer (Anaconda) automatically registers these sub‑volumes with the snapper service. Snapper maintains a series of read‑only snapshots under /var/lib/snapper. Each snapshot is identified by a numeric ID and a timestamp, and snapper tracks the parent‑child relationship to enable incremental rollbacks.

Verifying the Btrfs Filesystem and Sub‑Volumes

Before attempting any recovery, confirm that the installed system uses Btrfs and that the expected sub‑volumes are present. The following read‑only command lists the filesystem type for each block device:

lsblk -f

In the output, the FSTYPE column should show btrfs for the root partition (typically /dev/sda2 or similar). To enumerate sub‑volumes on that partition, mount the partition in read‑only mode from a live environment and run:

sudo mount -o ro /dev/sda2 /mnt

Then list sub‑volumes with:

btrfs subvolume list /mnt

The command will display entries such as:

ID 256 gen 12345 top level 5 path @
ID 257 gen 12346 top level 5 path @/.snapshots

The @ sub‑volume corresponds to the root filesystem, while @/.snapshots holds the snapper snapshots. If the /var/lib/machines sub‑volume exists, it will appear with a distinct path under the mount point.

Preparing a Live USB with GUI Tools

Fedora’s official live ISO includes the necessary drivers and utilities to access Btrfs partitions. Create a bootable USB stick using any standard Fedora ISO image. The creation process must not alter the target system’s disks; it only writes to the removable media.

After booting the live environment, install the graphical snapshot manager packages if they are not already present. Both GNOME Software and KDE Discover can perform this step, but the command line provides a reproducible method:

sudo dnf install btrfs-assistant snapper

The btrfs-assistant package adds a GNOME/KDE integration layer that presents snapper snapshots within the file manager. The snapper package provides the underlying snapshot management service.

Starting the Snapper Service in the Live Environment

When running from a live USB, the snapper daemon is not started automatically. Enable it for the current session with:

sudo systemctl start snapperd.service

This command launches the snapper daemon, which reads the snapshot metadata from the mounted Btrfs partition. The service runs only in the live session and will terminate when the system reboots.

Using the GUI to Browse and Restore Snapshots

With the live environment running and the Btrfs partition mounted (typically at /run/media/liveuser/ROOT), open the file manager. The integration added by btrfs-assistant displays a virtual folder named .snapshots inside the root view. Each entry corresponds to a snapper snapshot and is labeled with its numeric ID and creation date.

To restore a snapshot, follow these steps:

1. Identify the snapshot that represents a known-good system state. The timestamps shown in the folder names help select the appropriate point.
2. Right‑click the snapshot folder and choose “Mount” (or “Open”). This action mounts the snapshot read‑only at a temporary location, typically under /run/media/liveuser/.snapshots.
3. Copy the contents of the mounted snapshot back to the original root sub‑volume. Because the live environment is operating on a separate disk, the copy operation does not affect the live system.

The copy operation can be performed with the graphical file manager’s drag‑and‑drop interface, or, for precision, with a read‑only rsync command that preserves permissions:

sudo rsync -aAX --delete /run/media/liveuser/.snapshots/ID/snapshot/ /mnt/

Replace ID with the numeric identifier of the chosen snapshot. The --delete flag ensures that files removed after the snapshot are also removed, reproducing the exact state of the system at the snapshot time. This operation overwrites the current root filesystem; to reverse it, repeat the process with a later snapshot or with a fresh backup of the current state.

Verifying the Restored System

After the copy completes, unmount the live USB’s root mount point and reboot into the restored installation:

sudo umount /mnt
sudo reboot

If the boot proceeds without errors, the restoration succeeded. Should the system still fail to boot, repeat the process with an earlier snapshot. Because each snapshot is independent, the administrator can iterate until a functional state is reached.

Trade‑offs and Operational Considerations

The GUI‑based recovery workflow offers several advantages for administrators accustomed to graphical environments:

• Ease of use: No need to memorize complex btrfs command syntax; the file manager presents snapshots as ordinary folders.
• Safety: Operations are performed from a live USB, keeping the installed system offline and preventing accidental writes during recovery.
• Visibility: Snapshots are labeled with timestamps, making it straightforward to select the correct point in time.

However, the approach also has limitations that must be weighed against alternative methods:

• Disk space consumption: Snapper retains multiple read‑only snapshots; each snapshot consumes additional space proportional to the amount of changed data. Administrators should monitor /var/lib/snapper and prune old snapshots with snapper delete when necessary.
• Performance impact: Frequent snapshot creation can introduce write amplification on SSDs. Fedora’s default configuration balances snapshot frequency with system load, but workloads with intensive write patterns may require tuning.
• Recovery granularity: The GUI restores an entire sub‑volume. For targeted file recovery, the command line btrfs subvolume snapshot or direct mounting of a specific snapshot may be more appropriate.
• Dependency on snapper: The graphical integration relies on snapper’s metadata. If snapper’s database becomes corrupted, the GUI will not display snapshots, and manual btrfs commands will be required to reconstruct the snapshot list.

In environments where headless recovery is required, administrators can fall back to the command‑line equivalents: list snapshots with snapper list, mount a snapshot with btrfs subvolume snapshot -r, and restore using rsync or cp -a. The GUI workflow described above simply abstracts these steps into a point‑and‑click process while preserving the same underlying mechanisms.

Source: fedoramagazine.org