How BTRFS snapshots work and why they matter for dual-boot recovery
Short answer: BTRFS is a modern Linux filesystem that supports copy-on-write snapshots — point-in-time copies of the filesystem tree stored as separate subvolumes (logical divisions within the same BTRFS partition). Tools like Snapper (openSUSE, Fedora) and Timeshift (Ubuntu/Debian) create these automatically before every system update or on a schedule. On a dual-boot Linux + Windows system, BTRFS snapshots allow rolling back a broken Linux update in minutes, without affecting the Windows partition. The challenge arises when the snapshot exists but BTRFS itself is corrupted — typically from a power cut mid-operation or a Windows partition resize that overwrote the BTRFS chunk table.
How to recover BTRFS snapshots on a dual-boot Linux system
Step 1: Roll back a broken Linux update using Snapper
On openSUSE Leap or Tumbleweed with the default BTRFS + Snapper setup: restart the computer and watch for the GRUB bootloader menu. Select “Bootable Snapshots” from the GRUB menu. A list of timestamped snapshots appears — each corresponds to a system state before a previous update. Select the last known-good snapshot (the one just before the update that caused the problem) and boot from it. If it boots correctly, open a terminal and run sudo snapper rollback to make that snapshot the permanent default and create a new snapshot at the rollback point. On Fedora with btrfs-assistant or Snapper, the process is similar through the snapper-rollback package. For Timeshift on Ubuntu: boot from a live USB, open Timeshift, select the snapshot, and restore.
Step 2: Manually swap the default BTRFS subvolume
If the GRUB snapshot menu is not available (e.g., on Ubuntu with Timeshift where GRUB integration is not automatic), boot from a Linux live USB. Mount the BTRFS partition: sudo mount /dev/sdaX /mnt. List all subvolumes: sudo btrfs subvolume list /mnt. Find the snapshot you want to restore (identified by creation date in the path, typically /.snapshots/N/snapshot). Set it as the default subvolume: sudo btrfs subvolume set-default [ID] /mnt. Reboot from the installed system — Linux will boot from the snapshot subvolume as if it were the root. This is a powerful recovery method but requires identifying the correct snapshot ID — an incorrect ID will boot from the wrong point in time. For related filesystem recovery scenarios, see our ext4 Linux dual-boot recovery guide.
Step 3: Repair a corrupted BTRFS filesystem
If btrfs subvolume list fails or the partition will not mount, the filesystem itself may be corrupted. Before attempting any repair, image the entire drive: sudo ddrescue /dev/sdaX btrfs-backup.img btrfs-backup.log. Only after imaging, run the check: sudo btrfs check /dev/sdaX (read-only, no changes). If the check reports errors in the chunk tree, extent tree, or superblock, a full btrfs check --repair may fix them. Never run --repair on an unmounted partition without the ddrescue image as your fallback. For severe corruption (multiple tree errors), professional filesystem recovery tools or specialist assistance is more reliable than repair flags.
Step 4: The India angle — dual-boot partition conflicts
The most common BTRFS corruption scenario we encounter on Indian dual-boot laptops: the user was running low on Windows disk space, opened Windows Disk Management, extended the Windows partition, and inadvertently expanded it into the space occupied by the BTRFS partition. Windows Disk Management does not understand BTRFS and will happily write NTFS structures over the end of an adjacent BTRFS volume. The result is a corrupted BTRFS chunk tree (the structure that maps BTRFS logical addresses to physical disk positions). Recovery from this requires btrfs rescue chunk-recover /dev/sdaX, a specialised command that reconstructs the chunk table from physical block signatures. Success rate is moderate. Our data recovery service has handled BTRFS chunk tree rebuilds for Indian developers and data science students who run Ubuntu/Fedora alongside Windows.