Recovering BTRFS drive

Today my desktop had a lot of hanging issues, so I tried rebooting. I noticed there were error messages about being unable to write to swap or var/cacheduring the reboot. The system then hanged on The system will reboot now! message for a minute so I tried forcing shutdown by holding the power button.

After forced shutdown, my disk seems to be unable to mount (even on Live ISO), with error `can't read superblock on /dev/nvme0n1p2`. The output from lsblk -f is

NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
loop0 squashfs 4.0 0 100% /run/archiso/airootfs
sda
├─sda1 exfat 1.0 Ventoy EEA2-CB7C
└─sda2 vfat FAT16 VTOYEFI 9982-6B7C
sdb iso9660 Joliet Extension COS_202604 2026-04-26-09-32-03-00
├─sdb1 iso9660 Joliet Extension COS_202604 2026-04-26-09-32-03-00
└─sdb2 vfat FAT16 ARCHISO_EFI 69ED-DB93
zram0 swap 1 zram0 19c9aae7-529c-4f42-8b28-b5fcafef77c4 [SWAP]
nvme1n1
├─nvme1n1p1
├─nvme1n1p2 ntfs FAB0AB25B0AAE77B
├─nvme1n1p3 vfat FAT32 SYSTEM 1CBF-DF56
├─nvme1n1p4
└─nvme1n1p5 ntfs 863A335E3A334A87
nvme0n1
├─nvme0n1p1 vfat FAT32 0BAD-00CA
└─nvme0n1p2 btrfs arch cb7810f2-58a5-4953-b2ff-40be4bf179b4

though note that nvme1n1 is a Windows partition.

I also attempted btrfs check which failed with

parent transid verify failed on 1166427914240 wanted 859084 found 859063
parent transid verify failed on 1166427914240 wanted 859084 found 859063
parent transid verify failed on 1166427914240 wanted 859084 found 859063
Ignoring transid failure
ERROR: child eb corrupted: parent bytenr=1166426046464 item=72 parent level=2 child bytenr=1166427914240 child level=0
ERROR: failed to read block groups: Input/output error
ERROR: cannot open file system

I haven’t tried running a smartctl test to avoid risking damage to the filesystem but smartctl claims that there weren’t any error messages recorded by the relevant SSD. The boot partition itself also seems fine.

What BTRFS wizardry can I do now?

Look into btrfs restore and see if you can recover some or all of your files into another medium before attempting anything further.

btrfs check is stricter and needs enough metadata integrity to open the filesystem normally, while btrfs restore uses looser checks and can often extract data as long as the metadata it needs is still readable. So a failed repair does not mean recovery is impossible; it just means the filesystem is too damaged for normal consistency checking or repair.

Well just to try it out I did sudo btrfs restore /dev/nvme0n1p2 /tmp and it was able to pull some stuff out, but eventually failed with

ERROR: zstd frame incomplete
ERROR: copying data for /tmp/@/var/lib/pacman/local/sdl2_ttf-2.24.0-2.1/desc failed
ERROR: searching directory /tmp/@/var/lib/pacman/local/sdl2_ttf-2.24.0-2.1/desc failed: -1
ERROR: searching directory /tmp/@/var/lib/pacman/local/sdl2_ttf-2.24.0-2.1/desc failed: -1
ERROR: searching directory /tmp/@/var/lib/pacman/local/sdl2_ttf-2.24.0-2.1/desc failed: -1
ERROR: searching directory /tmp/@/var/lib/pacman/local/sdl2_ttf-2.24.0-2.1/desc failed: -1
ERROR: searching directory /tmp/@/var/lib/pacman/local/sdl2_ttf-2.24.0-2.1/desc failed: -1
ERROR: searching directory /tmp/@/var/lib/pacman/local/sdl2_ttf-2.24.0-2.1/desc failed: -1

Note that these errors only appeared when not using the -D option.

I did also try with the -s option, (for snapshots) which gave

ERROR: reading subvolume /tmp/@/.snapshots/1/snapshot/@.snapshots failed: 18446744073709551614
ERROR: searching directory /tmp/@/.snapshots/1/snapshot/@.snapshots failed: -2
ERROR: searching directory /tmp/@/.snapshots/1/snapshot/@.snapshots failed: -2
ERROR: searching directory /tmp/@/.snapshots/1/snapshot/@.snapshots failed: -2
ERROR: searching directory /tmp/@/.snapshots/1/snapshot/@.snapshots failed: -2

Anyways, is there any way of separating out by subvolume? Because it might be the case that some of my subvolumes are corrupted but my home subvolume is fine, I guess.

Not sure if /tmp of the Live USB would be an appropriate location to restore large chunks of data into.

Perhaps you could mount an external storage medium there (or somewhere convenient) to serve as your “recovery” directory.

btrfs restore -l should list the root ids of the subvolumes in the btrfs partition:

sudo btrfs -l /dev/nvme0n1p2

Dry run:

sudo btrfs -D -r <rootid> /dev/nvme0n1p2 /path/to/recovery

If the dry run looks good:

sudo btrfs restore -r <rootid> /dev/nvme0n1p2 /path/to/recovery

Please note that btrfs restore should operate on unmounted partition.

Also, if the data is critical to you, you might want to look at ways to clone your disk and work on the cloned disk rather than the actual damaged filesystem.

Would it additionally be possible to exclude certain folders? Considering most of my drive’s storage is taken up by Steam games which can be re-downloaded anyway.

Not that I know of. I don’t think btrfs restore operates on folder level.

Sorry for being away for a bit but I’ve been busy.

Not that I know of. I don’t think btrfs restore operates on folder level.

This is a bit of a problem because I don’t actually have any other SSDs on hand that are big enough to fit everything (~1.5TB) on the drive. Given how expensive SSDs are now I don’t think I can really afford to buy another SSD.

Regardless, I did try your advice to use an external storage medium, but I still got

ERROR: zstd frame incomplete
ERROR: copying data for /tmp/@/var/lib/pacman/local/sdl2_ttf-2.24.0-2.1/desc failed
ERROR: searching directory /tmp/@/var/lib/pacman/local/sdl2_ttf-2.24.0-2.1/desc failed: -1
ERROR: searching directory /tmp/@/var/lib/pacman/local/sdl2_ttf-2.24.0-2.1/desc failed: -1
ERROR: searching directory /tmp/@/var/lib/pacman/local/sdl2_ttf-2.24.0-2.1/desc failed: -1
ERROR: searching directory /tmp/@/var/lib/pacman/local/sdl2_ttf-2.24.0-2.1/desc failed: -1
ERROR: searching directory /tmp/@/var/lib/pacman/local/sdl2_ttf-2.24.0-2.1/desc failed: -1
ERROR: searching directory /tmp/@/var/lib/pacman/local/sdl2_ttf-2.24.0-2.1/desc failed: -1

like last time. Now I can force through these errors through -i but (because it looks like so much is just missing) I don’t think just copying everything through btrfs restore -i and then trying to boot from that will result in a usable system (if it even boots).

btrfs restore -l should list the root ids of the subvolumes in the btrfs partition:

sudo btrfs -l /dev/nvme0n1p2

After running this I got the following: 85fbe73

I have no idea how to read this. I suppose the majority of these are corrupted snapshots. I also used the subvolumes that came default with EndeavourOS, so I believe var/cache, var/log, home, tmp, and swap are all separate subvolumes from the “main” subvolume. No clear way of figuring out which is which though.

 tree key (256 ROOT_ITEM 0) 1166425276416 level 2
 tree key (257 ROOT_ITEM 0) 1166407630848 level 3
 tree key (258 ROOT_ITEM 0) 2622355685376 level 2
 tree key (259 ROOT_ITEM 0) 1166409154560 level 1
 tree key (260 ROOT_ITEM 0) 72007680 level 0
 tree key (261 ROOT_ITEM 0) 72073216 level 0
 tree key (265 ROOT_ITEM 0) 820229128192 level 1
 tree key (266 ROOT_ITEM 64960) 364134400 level 2

This seems to be the relevant part. My CachyOS is not using the “standard” subvolume layout so I cannot unfortunately check. However my suspicion is that 256 could be @ (the root of the system) and 257, @home.

I would check :

sudo btrfs restore -D -r 256 /dev/nvme0n1p2 /path/to/recovery

where /path/to/recovery is the path to where you have mounted the external storage medium.

Look at the output and see if you see @home. If not try 257 and so on.

Yeah, it’s 257, but it still fails with ERROR: zstd frame incomplete. (And even then I really don’t have the storage on-hand to just write the entire home directory to any of the SSDs I own…)

OK, I did end up acquiring a 2TB hard drive that I can potentially extract to. But I still get ERROR: zstd frame incomplete when attempting btrfs restore. Is there anything I can do?