You are not logged in.
Pages: 1
Hey, I did something terribly wrong, all blame on me. I wanted to write an USB stick but /dev/sdc wasn't the stick in this case but an attached btrfs HDD…
$ sudo dd bs=4M if=isofoo.iso of=/dev/sdc
483+1 Datensätze ein
483+1 Datensätze aus
2028060672 bytes (2,0 GB, 1,9 GiB) copied, 16,89 s, 120 MB/sSo, shit.
$ sudo btrfs check --repair /dev/sdc
enabling repair mode
No valid Btrfs found on /dev/sdc
Couldn't open file system$ sudo btrfs-find-root /dev/sdc
No valid Btrfs found on /dev/sdc
ERROR: open ctree failedOK, the btrfs wiki says there is a second superblock at 64 MiB (overwritten too in my case) and a third at 256 GiB ("0x4000000000"). But how to restore it? And how to restore the general btrfs frame metathings? Would be glad for any help!
Last edited by frumble (2016-06-12 21:13:07)
Offline
So, no backup ?. I've got bad news, and very bad news.
That link you referred is only referring to the "magic" text that identifies it as a btrfs filesystem. There are indeed more than one superblock, but on a 800Gig RAID5 filesystem of mine, there are only 2 - not the three one might expect from the wiki. I checked using "btrfs inspect-internal".
Even if there had been a third in your case, the underlying data has been smashed in the first 2 Gig. That may well include filesystem metadata. You could try adding "-s 2" to any command that accepts that to force it to look for a third super-block, but I wouldn't hold out much hope.
Maybe look at testdisk/photorec to attempt to scrape any recoverable file data.
Offline
Thank you. I was ending up writing to the LKML. At the end I had no luck and reformated the drive.
But it actually found the third btrfs superblock in my case. But it was like you've said, the underlying metadata was overwritten and even a 14 hours chunk recovery couldn't fix the holes.
Last edited by frumble (2016-06-22 18:47:26)
Offline
Pages: 1