I can no longer mount a usb btrfs hard drive that i was in the middle of coppying data to. I accidently unplugged the drives power. Whoops. Now the drive no longer mounts.
When running “sudo btrfs check /dev/sdb1” I get back
Opening filesystem to check…
checksum verify failed on 1065746432 wanted 0x00000000 found 0xb6bde3e4
checksum verify failed on 1065746432 wanted 0x00000000 found 0xb6bde3e4
checksum verify failed on 1065746432 wanted 0x00000000 found 0xb6bde3e4
bad tree block 1065746432, bytenr mismatch, want=1065746432, have=0
Couldn’t read tree root
ERROR: cannot open file system
Please help.
I canceled the transfer and rebooted but still cannot mount the drive.
i just tried running
❯ sudo btrfs rescue super-recover /dev/sdb1
All supers are valid, no need to recover
~
❯ sudo btrfs rescue zero-log /dev/sdb1
checksum verify failed on 1065746432 wanted 0x00000000 found 0xb6bde3e4
checksum verify failed on 1065746432 wanted 0x00000000 found 0xb6bde3e4
Couldn’t read tree root
ERROR: could not open ctree
just started a chunk recover
“sudo btrfs rescue chunk-recover /dev/sdb1”
seems like it will take a while on a 12tb drive…
ok, the chunk recover failed. I’m starting to wonder if the data on the drive is unrecoverable…
here is the output.
sudo btrfs rescue chunk-recover /dev/sdb1
Scanning: DONE in dev0
Couldn't read tree root
open with broken chunk error
Is there some way to fix the tree root?
I don’t want to conjure up demons, but maybe you should get used to the thought that the data might actually be lost. Perp tells me that by just trying to repair it, you may have destroyed more than before:
Before anything else: further writes to this disk, including “repair” attempts, can permanently destroy data. If the data matters, stop using the device, do a full sector‑level clone (e.g. ddrescue) and work only on the clone or hand it to a professional recovery service. Do not run any btrfs check --repair or additional btrfs rescue subcommands until you’ve decided you can afford to lose the filesystem.
and it continues talking about disk inconsistencies and whatnot. That sounds pretty severe.
Still, I wish the best of luck 
The data is not super critical. I was just starting to copy files on to it when this happened. I have a copy of (most) everything. There are some files that I only had on this drive, which will suck if i loose them, but nothing super critical. I would like to still try and recover the files if possible. ALso, if btrfs cannot handle a power outage, what linux filesystem can? I like the fact that btrfs does checksums and whatnot, but is there something more reliable should this happen again???
I don’t know 
I suffered 2 power failures lately and had no issues on both my btrfs and ext4 partitions yet :knock-on-wood:
were you writing to the drive when the 2 power outages happened?
I can’t really say for sure. I was in the middle of doing something to the system, not particularly a huge copy action. But there are processes doing stuff in the background all the time, right?
Ok, so i finally got the data back after persisting on. I sent a message to the btrfs mailing list team. They told me to run btrfs ins dump-super -f {dev}
This came back with
superblock: bytenr=65536, device=/dev/sdc1
csum_type 0 (crc32c)
csum_size 4
csum 0xa7602cf4 [match]
bytenr 65536
flags 0x1
( WRITTEN )
magic _BHRfS_M [match]
fsid 170f86c7-972d-4493-b13b-1046a34b5281
metadata_uuid 00000000-0000-0000-0000-000000000000
label 12TB WD Desktop Hard Drive
generation 569
root 1065746432
sys_array_size 129
chunk_root_generation 569
root_level 0
chunk_root 27394048
chunk_root_level 1
log_root 0
log_root_transid (deprecated) 0
log_root_level 0
total_bytes 12000136527872
bytes_used 633592479744
sectorsize 4096
nodesize 16384
leafsize (deprecated) 16384
stripesize 4096
root_dir 6
num_devices 1
compat_flags 0x0
compat_ro_flags 0xb
( FREE_SPACE_TREE |
FREE_SPACE_TREE_VALID |
BLOCK_GROUP_TREE )
incompat_flags 0x361
( MIXED_BACKREF |
BIG_METADATA |
EXTENDED_IREF |
SKINNY_METADATA |
NO_HOLES )
cache_generation 0
uuid_tree_generation 569
dev_item.uuid 2ed41ad3-7b25-4de5-8e37-1ba10381707b
dev_item.fsid 170f86c7-972d-4493-b13b-1046a34b5281 [match]
dev_item.type 0
dev_item.total_bytes 12000136527872
dev_item.bytes_used 638901551104
dev_item.io_align 4096
dev_item.io_width 4096
dev_item.sector_size 4096
dev_item.devid 1
dev_item.dev_group 0
dev_item.seek_speed 0
dev_item.bandwidth 0
dev_item.generation 0
sys_chunk_array[2048]:
item 0 key (FIRST_CHUNK_TREE CHUNK_ITEM 22020096)
length 8388608 owner 2 stripe_len 65536 type SYSTEM|DUP
io_align 65536 io_width 65536 sector_size 4096
num_stripes 2 sub_stripes 1
stripe 0 devid 1 offset 22020096
dev_uuid 2ed41ad3-7b25-4de5-8e37-1ba10381707b
stripe 1 devid 1 offset 30408704
dev_uuid 2ed41ad3-7b25-4de5-8e37-1ba10381707b
backup_roots[4]:
backup 0:
backup_tree_root: 1065746432 gen: 569 level: 0
backup_chunk_root: 27394048 gen: 569 level: 1
backup_extent_root: 1065533440 gen: 569 level: 1
backup_fs_root: 1065713664 gen: 569 level: 1
backup_dev_root: 1064697856 gen: 569 level: 1
csum_root: 1064796160 gen: 569 level: 2
backup_total_bytes: 12000136527872
backup_bytes_used: 633592479744
backup_num_devices: 1
backup 1:
backup_tree_root: 1060421632 gen: 566 level: 0
backup_chunk_root: 27246592 gen: 566 level: 1
backup_extent_root: 1060274176 gen: 566 level: 1
backup_fs_root: 1059667968 gen: 566 level: 1
backup_dev_root: 1059930112 gen: 566 level: 1
csum_root: 1059700736 gen: 566 level: 2
backup_total_bytes: 12000136527872
backup_bytes_used: 629965012992
backup_num_devices: 1
backup 2:
backup_tree_root: 1062191104 gen: 567 level: 0
backup_chunk_root: 27295744 gen: 567 level: 1
backup_extent_root: 1062010880 gen: 567 level: 1
backup_fs_root: 1061650432 gen: 567 level: 1
backup_dev_root: 1061453824 gen: 567 level: 1
csum_root: 1061683200 gen: 567 level: 2
backup_total_bytes: 12000136527872
backup_bytes_used: 631174152192
backup_num_devices: 1
backup 3:
backup_tree_root: 1064026112 gen: 568 level: 0
backup_chunk_root: 27344896 gen: 568 level: 1
backup_extent_root: 1063796736 gen: 568 level: 1
backup_fs_root: 1063567360 gen: 568 level: 1
backup_dev_root: 1063108608 gen: 568 level: 1
csum_root: 1063600128 gen: 568 level: 2
backup_total_bytes: 12000136527872
backup_bytes_used: 632383324160
backup_num_devices: 1
After running that they told me to use btrfs restore -t 1064026112 (dev) (restore path)
This worked perfectly. I was able to recover all the data up to where the transfer was interrupted. After recovering i reformated the drive. I just thought I’d share this good news. Lesson learned.