* Re: dd on wrong device, 1.9 GiB from the beginning has been overwritten, how to restore partition?
2016-06-12 21:22 dd on wrong device, 1.9 GiB from the beginning has been overwritten, how to restore partition? Maximilian Böhm
@ 2016-06-12 22:15 ` Martin Steigerwald
2016-06-12 22:49 ` Henk Slager
2016-06-12 23:02 ` Chris Murphy
2 siblings, 0 replies; 7+ messages in thread
From: Martin Steigerwald @ 2016-06-12 22:15 UTC (permalink / raw)
To: Maximilian Böhm; +Cc: linux-btrfs
Hi Maximilian,
On Sonntag, 12. Juni 2016 23:22:11 CEST Maximilian Böhm wrote:
> Hi there, I did something terribly wrong, all blame on me. I wanted to
> write to an USB stick but /dev/sdc wasn't the stick in this case but
> an attached HDD with GPT and an 8 TB btrfs partition…
>
> $ sudo dd bs=4M if=manjaro-kde-16.06.1-x86_64.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/s
>
> So, 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 failed
>
> $ sudo btrfs-show-super /dev/sdc --all
> superblock: bytenr=65536, device=/dev/sdc
> ---------------------------------------------------------
> ERROR: bad magic on superblock on /dev/sdc at 65536
>
> superblock: bytenr=67108864, device=/dev/sdc
> ---------------------------------------------------------
> ERROR: bad magic on superblock on /dev/sdc at 67108864
>
> superblock: bytenr=274877906944, device=/dev/sdc
> ---------------------------------------------------------
> ERROR: bad magic on superblock on /dev/sdc at 274877906944
>
>
> System infos:
>
> $ uname -a
> Linux Mongo 4.6.2-1-MANJARO #1 SMP PREEMPT Wed Jun 8 11:00:08 UTC 2016
> x86_64 GNU/Linux
>
> $ btrfs --version
> btrfs-progs v4.5.3
>
> Don't think dmesg is necessary here.
>
>
> OK, 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 header
> metadata? How to restore GPT without doing something terrible again?
> Would be glad for any help!
But it says bad magic on that one as well.
Well, no idea if there is any chance to fix BTRFS in this situation.
Does btrfs restore do anything useful to copy of what if can find from this
device? It does not work in place, so you need an additional space to let it
restore to.
If BTRFS cannot be salvaged… you can still have a go with photorec, but it
will not recover filenames and directory structure, just the data of any file
of a file in a known format that it finds in one piece.
I suspect you have no backup.
So *good* luck.
I do think tough that dd should just bail out or warn for a BTRFS filesystem
that is still mounted, or wasn´t it mounted at that time?
I also think it would be good to add an existing filesystem check just like in
mkfs.btrfs, mkfs.xfs and so on. I´d like that, but that would be a suggestions
for the coreutils people.
Yes, Unix is for people who know what they are doing… unless they don´t. And
in the end even one of the most experienced admin could make such a mistake.
Goodnight,
--
Martin
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: dd on wrong device, 1.9 GiB from the beginning has been overwritten, how to restore partition?
2016-06-12 21:22 dd on wrong device, 1.9 GiB from the beginning has been overwritten, how to restore partition? Maximilian Böhm
2016-06-12 22:15 ` Martin Steigerwald
@ 2016-06-12 22:49 ` Henk Slager
2016-06-13 4:51 ` Andrei Borzenkov
2016-06-12 23:02 ` Chris Murphy
2 siblings, 1 reply; 7+ messages in thread
From: Henk Slager @ 2016-06-12 22:49 UTC (permalink / raw)
To: Maximilian Böhm; +Cc: linux-btrfs
On Sun, Jun 12, 2016 at 11:22 PM, Maximilian Böhm <winlux@gmail.com> wrote:
> Hi there, I did something terribly wrong, all blame on me. I wanted to
> write to an USB stick but /dev/sdc wasn't the stick in this case but
> an attached HDD with GPT and an 8 TB btrfs partition…
GPT has a secondary copy at the end of the device, so maybe gdisk can
reconstruct in first main one at the beginning of the disk, I don't
know all gdisk commands. But is you once created just 1 partition max
size for the whole disk with modern tools, your btrfs fs starts at
sector 2048, (with logical sectorsize 512).
> $ sudo dd bs=4M if=manjaro-kde-16.06.1-x86_64.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/s
To confuse btrfs+tools as little as possible, I would first overwrite
/dev/sdc again from the start with the same amount of bytes byte then
from /dev/zero.
Then create / 'newly overlay' a the original partition offset 1M, till
the end. Alternatively:
$ losetup /dev/loopX -o 1M /dev/sdc
then your broken fs will be on /dev/sdc1 or /dev/loopX
Or overlay it with dm, snapshot, set the original ro and then work on
the rw flavor, so you keep the current broken HDD/fs as is and then do
the above.
> $ sudo btrfs check --repair /dev/sdc
> enabling repair mode
> No valid Btrfs found on /dev/sdc
> Couldn't open file system
Forget --repair I would say, hopefully btrfs restore can still find /
copy most of the data
> $ sudo btrfs-find-root /dev/sdc
> No valid Btrfs found on /dev/sdc
> ERROR: open ctree failed
>
> $ sudo btrfs-show-super /dev/sdc --all
> superblock: bytenr=65536, device=/dev/sdc
> ---------------------------------------------------------
> ERROR: bad magic on superblock on /dev/sdc at 65536
>
> superblock: bytenr=67108864, device=/dev/sdc
> ---------------------------------------------------------
> ERROR: bad magic on superblock on /dev/sdc at 67108864
>
> superblock: bytenr=274877906944, device=/dev/sdc
> ---------------------------------------------------------
> ERROR: bad magic on superblock on /dev/sdc at 274877906944
run
$ sudo btrfs-show-super /dev/sdc1 --all
or
$ sudo btrfs-show-super /dev/loopX --all
> System infos:
>
> $ uname -a
> Linux Mongo 4.6.2-1-MANJARO #1 SMP PREEMPT Wed Jun 8 11:00:08 UTC 2016
> x86_64 GNU/Linux
>
> $ btrfs --version
> btrfs-progs v4.5.3
>
> Don't think dmesg is necessary here.
>
>
> OK, 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 header
> metadata? How to restore GPT without doing something terrible again?
See above, maybe you have lookup various sizes etc GPT etc first, but
I think your 3rd SB should be there.
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: dd on wrong device, 1.9 GiB from the beginning has been overwritten, how to restore partition?
2016-06-12 22:49 ` Henk Slager
@ 2016-06-13 4:51 ` Andrei Borzenkov
2016-06-14 14:34 ` Maximilian Böhm
0 siblings, 1 reply; 7+ messages in thread
From: Andrei Borzenkov @ 2016-06-13 4:51 UTC (permalink / raw)
To: Henk Slager, Maximilian Böhm; +Cc: linux-btrfs
13.06.2016 01:49, Henk Slager пишет:
> On Sun, Jun 12, 2016 at 11:22 PM, Maximilian Böhm <winlux@gmail.com> wrote:
>> Hi there, I did something terribly wrong, all blame on me. I wanted to
>> write to an USB stick but /dev/sdc wasn't the stick in this case but
>> an attached HDD with GPT and an 8 TB btrfs partition…
>
> GPT has a secondary copy at the end of the device, so maybe gdisk can
> reconstruct in first main one at the beginning of the disk, I don't
> know all gdisk commands.
kernel should automatically fall back to secondary GPT if booted with
gpt=1 parameter. Otherwise it is 'x' for expert mode and 'b' to rebuild
primary GPT from secondary copy. Also 'c' to load partition information
from secondary (without writing anything). But note that kernel will
also check for valid PMBR (unless gpt is force with parameter mentioned
above), so you will need yet another 'x' to enter second expert mode and
'n' to create new protective MBR.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: dd on wrong device, 1.9 GiB from the beginning has been overwritten, how to restore partition?
2016-06-13 4:51 ` Andrei Borzenkov
@ 2016-06-14 14:34 ` Maximilian Böhm
2016-06-20 14:24 ` Maximilian Böhm
0 siblings, 1 reply; 7+ messages in thread
From: Maximilian Böhm @ 2016-06-14 14:34 UTC (permalink / raw)
Cc: linux-btrfs
Wow, I'm overwhelmed, thank you very much for your help!
So, firstly I did a
dd if=/dev/zero of=nullz.raw bs=1 count=0 seek=2028060672
and overwrote the ISO on the HDD.
Then I was able to restore the GPT using gdisk with "use backup GPT
header (rebuilding main)". Now I have an intact GPT, a displayed
partition with original name, and an unknown filesystem.
btrfs check --repair /dev/sdc1
and
btrfs-show-super /dev/sdc1 --all
still don't work.
But I btrfs-show-super now finds the third superblock (see at the
bottom of this mail).
Then I tried btrfs restore with -u (superblock 3, because it's 0, 1, 2):
$ losetup /dev/loop1 -o 1M /dev/sdc
$ btrfs restore /dev/loop1 -l -u 2
checksum verify failed on 21004288 found E4E3BDB6 wanted 00000000
checksum verify failed on 21004288 found E4E3BDB6 wanted 00000000
checksum verify failed on 21004288 found E4E3BDB6 wanted 00000000
checksum verify failed on 21004288 found E4E3BDB6 wanted 00000000
bytenr mismatch, want=21004288, have=0
ERROR: cannot read chunk root
Could not open root, trying backup super
Hm, doesn't "-u 2" defines the backup superblock 3?
$ btrfsck /dev/loop1
No valid Btrfs found on /dev/loop1
Couldn't open file system
BTW, Photorecs finds lots of files but e.g. MKV video are corrupted in
some form that they don't want to play but KDE's Dolphin is able to
generate previews in some cases.
Any idea about how I should proceed further?
$ btrfs-show-super /dev/sdc1 --all
superblock: bytenr=65536, device=/dev/sdc1
---------------------------------------------------------
ERROR: bad magic on superblock on /dev/sdc1 at 65536
superblock: bytenr=67108864, device=/dev/sdc1
---------------------------------------------------------
ERROR: bad magic on superblock on /dev/sdc1 at 67108864
superblock: bytenr=274877906944, device=/dev/sdc1
---------------------------------------------------------
csum 0x615e669a [match]
bytenr 274877906944
flags 0x1
( WRITTEN )
magic _BHRfS_M [match]
fsid 446c7a9c-fcad-42f2-b093-ee495ca8f5be
label Speicherschatz
generation 5503
root 5113205555200
sys_array_size 129
chunk_root_generation 5485
root_level 1
chunk_root 21004288
chunk_root_level 1
log_root 0
log_root_transid 0
log_root_level 0
total_bytes 8001561821184
bytes_used 6272827662336
sectorsize 4096
nodesize 16384
leafsize 16384
stripesize 4096
root_dir 6
num_devices 1
compat_flags 0x0
compat_ro_flags 0x0
incompat_flags 0x169
( MIXED_BACKREF |
COMPRESS_LZO |
BIG_METADATA |
EXTENDED_IREF |
SKINNY_METADATA )
csum_type 0
csum_size 4
cache_generation 5503
uuid_tree_generation 5503
dev_item.uuid 0471bf89-89d1-424a-9fc1-d48241ff453b
dev_item.fsid 446c7a9c-fcad-42f2-b093-ee495ca8f5be [match]
dev_item.type 0
dev_item.total_bytes 8001561821184
dev_item.bytes_used 6283562319872
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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: dd on wrong device, 1.9 GiB from the beginning has been overwritten, how to restore partition?
2016-06-14 14:34 ` Maximilian Böhm
@ 2016-06-20 14:24 ` Maximilian Böhm
0 siblings, 0 replies; 7+ messages in thread
From: Maximilian Böhm @ 2016-06-20 14:24 UTC (permalink / raw)
To: linux-btrfs
Hey, I want you to know that it was impossible to recover the filesystem and that I have recreated the partition. Lost ~1.5 TiB unredundant data but it's just an annoyance, no catastrophe – I can recreate my collection and it wasn't any critical data.
For others with related problems: My latest attempt was to recover the superblock and metadata:
$ btrfs rescue super-recover -v /dev/sdc1
All Devices:
Device: id = 1, name = /dev/sdc1
Before Recovering:
[All good supers]:
device name = /dev/sdc1
superblock bytenr = 274877906944
[All bad supers]:
device name = /dev/sdc1
superblock bytenr = 65536
device name = /dev/sdc1
superblock bytenr = 67108864
Make sure this is a btrfs disk otherwise the tool will destroy other fs, Are you sure? [y/N]: y
checksum verify failed on 21004288 found E4E3BDB6 wanted 00000000
checksum verify failed on 21004288 found E4E3BDB6 wanted 00000000
checksum verify failed on 21004288 found E4E3BDB6 wanted 00000000
checksum verify failed on 21004288 found E4E3BDB6 wanted 00000000
bytenr mismatch, want=21004288, have=0
ERROR: cannot read chunk root
Failed to recover bad superblocks
*** Error in `btrfs': double free or corruption (fasttop): 0x0000000000946010 ***
======= Backtrace: =========
/usr/lib/libc.so.6(+0x6ed4b)[0x7fa620c8cd4b]
/usr/lib/libc.so.6(+0x74546)[0x7fa620c92546]
/usr/lib/libc.so.6(+0x74d1e)[0x7fa620c92d1e]
btrfs(btrfs_close_devices+0xf7)[0x456227]
btrfs(btrfs_recover_superblocks+0x459)[0x437729]
btrfs(main+0x7b)[0x40ac3b]
/usr/lib/libc.so.6(__libc_start_main+0xf1)[0x7fa620c3e741]
btrfs(_start+0x29)[0x40ad39]
======= Memory map: ========
00400000-00495000 r-xp 00000000 00:13 4097939 /usr/bin/btrfs
00694000-00698000 r--p 00094000 00:13 4097939 /usr/bin/btrfs
00698000-0069a000 rw-p 00098000 00:13 4097939 /usr/bin/btrfs
0069a000-0069f000 rw-p 00000000 00:00 0
00946000-00967000 rw-p 00000000 00:00 0 [heap]
7fa61c000000-7fa61c021000 rw-p 00000000 00:00 0
7fa61c021000-7fa620000000 ---p 00000000 00:00 0
7fa620a06000-7fa620a1c000 r-xp 00000000 00:13 3704352 /usr/lib/libgcc_s.so.1
7fa620a1c000-7fa620c1b000 ---p 00016000 00:13 3704352 /usr/lib/libgcc_s.so.1
7fa620c1b000-7fa620c1c000 rw-p 00015000 00:13 3704352 /usr/lib/libgcc_s.so.1
7fa620c1e000-7fa620db5000 r-xp 00000000 00:13 3867364 /usr/lib/libc-2.23.so
7fa620db5000-7fa620fb5000 ---p 00197000 00:13 3867364 /usr/lib/libc-2.23.so
7fa620fb5000-7fa620fb9000 r--p 00197000 00:13 3867364 /usr/lib/libc-2.23.so
7fa620fb9000-7fa620fbb000 rw-p 0019b000 00:13 3867364 /usr/lib/libc-2.23.so
7fa620fbb000-7fa620fbf000 rw-p 00000000 00:00 0
7fa620fc6000-7fa620fde000 r-xp 00000000 00:13 3867345 /usr/lib/libpthread-2.23.so
7fa620fde000-7fa6211dd000 ---p 00018000 00:13 3867345 /usr/lib/libpthread-2.23.so
7fa6211dd000-7fa6211de000 r--p 00017000 00:13 3867345 /usr/lib/libpthread-2.23.so
7fa6211de000-7fa6211df000 rw-p 00018000 00:13 3867345 /usr/lib/libpthread-2.23.so
7fa6211df000-7fa6211e3000 rw-p 00000000 00:00 0
7fa6211e6000-7fa621207000 r-xp 00000000 00:13 6889 /usr/lib/liblzo2.so.2.0.0
7fa621207000-7fa621406000 ---p 00021000 00:13 6889 /usr/lib/liblzo2.so.2.0.0
7fa621406000-7fa621407000 r--p 00020000 00:13 6889 /usr/lib/liblzo2.so.2.0.0
7fa621407000-7fa621408000 rw-p 00021000 00:13 6889 /usr/lib/liblzo2.so.2.0.0
7fa62140e000-7fa621423000 r-xp 00000000 00:13 7051 /usr/lib/libz.so.1.2.8
7fa621423000-7fa621622000 ---p 00015000 00:13 7051 /usr/lib/libz.so.1.2.8
7fa621622000-7fa621623000 r--p 00014000 00:13 7051 /usr/lib/libz.so.1.2.8
7fa621623000-7fa621624000 rw-p 00015000 00:13 7051 /usr/lib/libz.so.1.2.8
7fa621626000-7fa621664000 r-xp 00000000 00:13 3436728 /usr/lib/libblkid.so.1.1.0
7fa621664000-7fa621863000 ---p 0003e000 00:13 3436728 /usr/lib/libblkid.so.1.1.0
7fa621863000-7fa621867000 r--p 0003d000 00:13 3436728 /usr/lib/libblkid.so.1.1.0
7fa621867000-7fa621868000 rw-p 00041000 00:13 3436728 /usr/lib/libblkid.so.1.1.0
7fa621868000-7fa621869000 rw-p 00000000 00:00 0
7fa62186e000-7fa621872000 r-xp 00000000 00:13 3436727 /usr/lib/libuuid.so.1.3.0
7fa621872000-7fa621a71000 ---p 00004000 00:13 3436727 /usr/lib/libuuid.so.1.3.0
7fa621a71000-7fa621a72000 r--p 00003000 00:13 3436727 /usr/lib/libuuid.so.1.3.0
7fa621a72000-7fa621a73000 rw-p 00004000 00:13 3436727 /usr/lib/libuuid.so.1.3.0
7fa621a76000-7fa621a99000 r-xp 00000000 00:13 3867363 /usr/lib/ld-2.23.so
7fa621c95000-7fa621c99000 rw-p 00000000 00:00 0
7fa621c99000-7fa621c9a000 r--p 00023000 00:13 3867363 /usr/lib/ld-2.23.so
7fa621c9a000-7fa621c9b000 rw-p 00024000 00:13 3867363 /usr/lib/ld-2.23.so
7fa621c9b000-7fa621c9d000 rw-p 00000000 00:00 0
7fa621c9d000-7fa621c9f000 rw-p 00000000 00:00 0
7ffd2178f000-7ffd217b0000 rw-p 00000000 00:00 0 [stack]
7ffd217ee000-7ffd217f1000 r--p 00000000 00:00 0 [vvar]
7ffd217f1000-7ffd217f3000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Abgebrochen
So this failed. Then I discovered the btrfs rescue chunk-recover tool:
$ btrfs rescue chunk-recover -v /dev/sdc1
All Devices:
Device: id = 1, name = /dev/sdc1
Scanning: xxx in dev0
This took about 14 hours for the 7.2 TiB HDD but ended up with an impressive long error output: https://twitter.com/cyberfrumble/status/743099729110781952 (forgot to copy it, it was longer than the terminal history).
Then I gave up, created a new GPT and new btrfs partition. But thank you anyway for your recommendations! We can take away from this that we should check the device name each and every time before we do any dd stuff. ;)
Am 14.06.2016 um 16:34 schrieb Maximilian Böhm:
> Wow, I'm overwhelmed, thank you very much for your help!
>
> So, firstly I did a
> dd if=/dev/zero of=nullz.raw bs=1 count=0 seek=2028060672
> and overwrote the ISO on the HDD.
>
> Then I was able to restore the GPT using gdisk with "use backup GPT
> header (rebuilding main)". Now I have an intact GPT, a displayed
> partition with original name, and an unknown filesystem.
>
> btrfs check --repair /dev/sdc1
> and
> btrfs-show-super /dev/sdc1 --all
>
> still don't work.
>
> But I btrfs-show-super now finds the third superblock (see at the
> bottom of this mail).
>
> Then I tried btrfs restore with -u (superblock 3, because it's 0, 1, 2):
>
> $ losetup /dev/loop1 -o 1M /dev/sdc
> $ btrfs restore /dev/loop1 -l -u 2
> checksum verify failed on 21004288 found E4E3BDB6 wanted 00000000
> checksum verify failed on 21004288 found E4E3BDB6 wanted 00000000
> checksum verify failed on 21004288 found E4E3BDB6 wanted 00000000
> checksum verify failed on 21004288 found E4E3BDB6 wanted 00000000
> bytenr mismatch, want=21004288, have=0
> ERROR: cannot read chunk root
> Could not open root, trying backup super
>
> Hm, doesn't "-u 2" defines the backup superblock 3?
>
>
> $ btrfsck /dev/loop1
> No valid Btrfs found on /dev/loop1
> Couldn't open file system
>
> BTW, Photorecs finds lots of files but e.g. MKV video are corrupted in
> some form that they don't want to play but KDE's Dolphin is able to
> generate previews in some cases.
> Any idea about how I should proceed further?
>
>
>
>
> $ btrfs-show-super /dev/sdc1 --all
> superblock: bytenr=65536, device=/dev/sdc1
> ---------------------------------------------------------
> ERROR: bad magic on superblock on /dev/sdc1 at 65536
>
> superblock: bytenr=67108864, device=/dev/sdc1
> ---------------------------------------------------------
> ERROR: bad magic on superblock on /dev/sdc1 at 67108864
>
> superblock: bytenr=274877906944, device=/dev/sdc1
> ---------------------------------------------------------
> csum 0x615e669a [match]
> bytenr 274877906944
> flags 0x1
> ( WRITTEN )
> magic _BHRfS_M [match]
> fsid 446c7a9c-fcad-42f2-b093-ee495ca8f5be
> label Speicherschatz
> generation 5503
> root 5113205555200
> sys_array_size 129
> chunk_root_generation 5485
> root_level 1
> chunk_root 21004288
> chunk_root_level 1
> log_root 0
> log_root_transid 0
> log_root_level 0
> total_bytes 8001561821184
> bytes_used 6272827662336
> sectorsize 4096
> nodesize 16384
> leafsize 16384
> stripesize 4096
> root_dir 6
> num_devices 1
> compat_flags 0x0
> compat_ro_flags 0x0
> incompat_flags 0x169
> ( MIXED_BACKREF |
> COMPRESS_LZO |
> BIG_METADATA |
> EXTENDED_IREF |
> SKINNY_METADATA )
> csum_type 0
> csum_size 4
> cache_generation 5503
> uuid_tree_generation 5503
> dev_item.uuid 0471bf89-89d1-424a-9fc1-d48241ff453b
> dev_item.fsid 446c7a9c-fcad-42f2-b093-ee495ca8f5be [match]
> dev_item.type 0
> dev_item.total_bytes 8001561821184
> dev_item.bytes_used 6283562319872
> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: dd on wrong device, 1.9 GiB from the beginning has been overwritten, how to restore partition?
2016-06-12 21:22 dd on wrong device, 1.9 GiB from the beginning has been overwritten, how to restore partition? Maximilian Böhm
2016-06-12 22:15 ` Martin Steigerwald
2016-06-12 22:49 ` Henk Slager
@ 2016-06-12 23:02 ` Chris Murphy
2 siblings, 0 replies; 7+ messages in thread
From: Chris Murphy @ 2016-06-12 23:02 UTC (permalink / raw)
To: Maximilian Böhm; +Cc: Btrfs BTRFS
On Sun, Jun 12, 2016 at 3:22 PM, Maximilian Böhm <winlux@gmail.com> wrote:
> Hi there, I did something terribly wrong, all blame on me. I wanted to
> write to an USB stick but /dev/sdc wasn't the stick in this case but
> an attached HDD with GPT and an 8 TB btrfs partition…
>
> $ sudo dd bs=4M if=manjaro-kde-16.06.1-x86_64.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/s
>
> So, 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 failed
>
> $ sudo btrfs-show-super /dev/sdc --all
> superblock: bytenr=65536, device=/dev/sdc
> ---------------------------------------------------------
> ERROR: bad magic on superblock on /dev/sdc at 65536
>
> superblock: bytenr=67108864, device=/dev/sdc
> ---------------------------------------------------------
> ERROR: bad magic on superblock on /dev/sdc at 67108864
>
> superblock: bytenr=274877906944, device=/dev/sdc
> ---------------------------------------------------------
> ERROR: bad magic on superblock on /dev/sdc at 274877906944
>
>
OK but none of these can work anyway because the tools work based on
fixed offsets. By pointing the tool to /dev/sdc the wrong offset is
always being used, because originally the drive had a partition. By
default GPT disks offset the 1st partition 1MiB, or 2048 using 512
byte sectors assuming the drive uses 512 byte logical sectors (and
most still do).
What you should do is run gdisk /dev/sdc and it'll find the backup GPT
at the end of the drive, and offer to fix up the primary one. And now
you can point the tools to /dev/sdc1 (or whatever partition is for
Btrfs).
2GIB of Btrfs metadata is a lot of missing metadata though. So even
though btrfs-show-super will find the 3rd superblock, chances are it's
going to point to metadata somewhere in those first 2GiB that were
overwritten, but maybe not. It might be possible to get a -o ro mount
at least and start copying off some data.
If it's ro mountable, it might be possible to put /dev/sdc1 on an
overlay, and then fix the overlay rather than the original with
btrfsck - maybe it can fix up enough such that you'll just get piles
of read errors for the data that's missing rather than hitting some
brick wall and stopping.
--
Chris Murphy
^ permalink raw reply [flat|nested] 7+ messages in thread