A kernel, driver, or package update can leave a machine or VM in an unusable state. If your root is on Btrfs, a snapshot taken just before the operation keeps a local return point, provided you target the correct subvolume.
The method below creates a read-only copy, then checks that it really exists. It does not replace a backup and does not initiate automatic system restoration.
Confirm that the root is a Btrfs subvolume
Do not initiate a snapshot just because the machine uses Btrfs somewhere. You need to check the filesystem that holds /, then identify the mounted subvolume. On a remote server, keep your SSH session open throughout the verification.
findmnt -T / -o TARGET,SOURCE,FSTYPE,OPTIONS
sudo btrfs subvolume show /
sudo btrfs subvolume list -p /
sudo btrfs filesystem usage /The first command should display btrfs in the FSTYPE column. btrfs subvolume show / confirms that the root corresponds to a subvolume. Also check the unallocated space and free space, as a snapshot initially shares existing blocks, then consumes space as files change.
This procedure targets a Btrfs root mounted as a subvolume. If /home is separate, take a distinct snapshot for the data that must follow the rollback. On a machine configured with LVM, ext4, or XFS, these commands are not suitable.
Create a copy before the update
Choose a snapshots directory located on the same Btrfs filesystem. The example creates a dated name and a read-only copy. Adjust the path if your distribution or snapshot tool already uses a dedicated location.
sudo install -d -m 700 /@snapshots
sudo btrfs subvolume snapshot -r / /@snapshots/root-before-update-2026-09-02The -r option protects this return point against accidental modification. Wait for the command to finish before initiating apt upgrade, dnf upgrade, or your usual procedure. The Btrfs documentation describes this snapshot mechanism and the properties of subvolumes.
I would reserve this command for a root whose mounting you have read. Creating a snapshot from the wrong path gives a false sense of security, then does not restore the system that has actually been modified.
Check the return point after the update
A snapshot reported by the terminal is not yet a sufficient check. List it, display its properties, then reboot and check the service or application affected by the update.
sudo btrfs subvolume list /@snapshots
sudo btrfs subvolume show /@snapshots/root-before-update-2026-09-02
sudo btrfs property get -ts /@snapshots/root-before-update-2026-09-02 roThe last command should indicate ro=true. Keep the snapshot until the boot and the affected services are validated. Once the update is validated, you can delete it to reclaim blocks that are no longer shared.
sudo btrfs subvolume delete /@snapshots/root-before-update-2026-09-02Do not delete a copy that you might still need to diagnose a regression. If the machine does not reboot anymore, the way forward depends on the bootloader, the layout of the subvolumes, and the snapshot management tool. Prepare this procedure before the incident, rather than from a rescue session.
A local snapshot does not protect the disk
The snapshot remains on the same Btrfs pool. A disk failure, an inaccessible encrypted volume, or a pool deletion can wipe out the root and its snapshots. To recover a file after a hardware incident, also keep a backup outside of the pool. Our method to verify a BorgBackup restoration complements this check.
The choice is simple: snapshot for quick rollback after an update, separate backup to survive storage loss. Both address different failures.
For details on subvolumes and their snapshots, the Btrfs documentation remains the useful reference before changing the organization of an existing system.