[how to] rescue data from a damaged btrfs volume

Difficulty: ★★☆☆☆

:uk: :de:

You used btrfs. Now it’s paying off. There is an easy way out (I’ve already done this myself):

In most cases, when a btrfs volume breaks, it is possible to recover the data
  • This is because btrfs works with copy on write. This means that new changes are always appended at the end, so to speak. The previously existing data is not actually overwritten. (In reality this is a bit more complicated, but for us here this simplified view is sufficient).
  • If the file system gets corrupted, then the corruption is at the very end. When ro-mount, btrfs can find the corruption and hide this last damaged part. We then see the file system in the state shortly (possibly 5 seconds) before the corruption. You can get this undamaged data with the following actions:

In contrast to other file systems, no special programs are required for this. On the contrary the best way to rescue the data from a btrfs volume is to use btrfs-tools !

Above all: Under no circumstances try to mount the damaged volume rw as long as the data has not been rescued.

Recover data from damaged btrfs volume
  • Boot into a recovery system (DVD or USB …) if possible with a current LTS kernel (e.g. 5.10)
  • mount your damaged btrfs volume as ro (read only). This mount corresponds to a snapshot of the last working state of the volume
  • Now you can take one of 2 ways:
    • rescue entire volume with all subvolumes and snapshots (my recommendation!)
    • rescue a specific subvolume or a specific snapshot
      • View all subvolumes. With a file manager (e.g. mc) search for the subvolume on which the desired data is located. The subvolumes can have completely different layouts. You can find more information if you google for “btrfs-layout”.
  • mount an (empty) btrfs volume with plenty of space rw. It does not have to be the same size as the damaged one, but it must be large enough to hold the contents of the volume to be rescued (including the suvolumes / snapshots).
  • Use btrfs send to transfer the entire contents of the damaged volume to the new backup volume
  • Check the data on the backup volume. Is everything there? Then umount the backup volume
  • If you see a chance to fix the damaged btrfs “in place”, you can try now. Otherwise, just continue here
Restore the volume
  • umount the damaged btrfs volume and reformat it as btrfs, e.g. with gparted (we do have a backup)
  • mount the backup ro (readonly) (better safe than sorry)
  • Use btrfs send to restore the data to the newly created volume

If that worked you will not only get all the data of the last status, but also all subvolumes and all snapshots that you had.

Tips for the future:
  • If you are worried that the data on a btrfs volume has been corrupted, test it with btrfs scrub
  • Please use btrfs balance sparingly. Most of the time it is unnecessary and only burdens the system. And if so, please always use it with limits (e.g. 75% or 50%)
  • Take automatic snapshots (e.g. with snapper ). If possible every hour. With btrfs it doesn’t cost anything. Snapper can also automatically free these snapshots after a set time. (delete seems the wrong term here)
  • If you have several (2, 3 or 4) devices and can combine them into one btrfs volume, then use RAID1
  • Don’t forget to make good backups of your data. btrfs send is your friend

You can find good information about btrfs in the btrfs-wiki at kernel.org and in the arch-wiki

Viel Erfolg ! :sunglasses:



When doing data recovery, I always tell people to ddrescue or Backup their volume before starting any repairs because then you can still restore your backup if you do something wrong…

Great idea posting both an :uk: and :de: version!

You are right! But Step 1 is not a repair, but a backup.
The way i suggest, is to not to alter the volume in any way, but first rescue(backup) all data. It is mounted readonly to rescue data. If the disk is not 100% full, this is faster then dd because only necessary chunks are copied.

1 Like