I have an external hdd that doesn't mount anymore. I think I screw up with all the research I done and things I try. I have vital info on this hdd and I'm really afraid to lose it.
I tried this: Rebuild partition table on external HDD – not writable but run into a problem:
sudo pdisk /dev/rdisk1
pdisk: No valid block 1 on '/dev/rdisk2' Edit /dev/rdisk2 - Command (? for help):
I tried a scan with Disk Drill and it seems that the data is there but after I tried to recover a few files, I can't open them. They have the size but I can't open them.
I tried repairdisk:
diskutil repairdisk /dev/disk2
Repairing the partition map might erase disk2s1, proceed? (y/N) y
Started partition map repair on disk2
Checking prerequisites
Checking the partition list
Problems were encountered during repair of the partition map
Error: -69770: Partition map check failed because no slices were found
I've tried test disk and before the quick search I get his:
Bad MAC partition, invalid block0 signature read_part_mac: bad DPME signature
after the quick search this is my result
Also tried:
pdisk: No valid block 1 on '/dev/rdisk2' Edit /dev/rdisk2 - Command (? for help):
Update:
Instead of using pdisk I tried gpt. The result of sudo gpt -r show /dev/disk3
is:
start size index contents
0 1 PMBR
1 1 Pri GPT header
2 4 Pri GPT table
6 34
40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
409640 243781000
244190640 4 Sec GPT table
244190644 1 Sec GPT header
I've changed the hdd to a firewire 800 enclosure
The result of sudo gpt -r show /dev/disk2
is:
start size index contents
0 1 PMBR
1 1953525167
Update 2
Trying to find the EFI start block:
Best Answer
The disk lost its GUID partition table and the EFI volume was partly overwritten. The disk was mounted in an enclosure which doesn't properly report a logical block size of 512 bytes. Instead 4096 bytes are used. The disk itself has a physical block size of 4096 bytes.
After trying some known but actually unsuccessful methods (e.g. Disk Warrior or answers here at stackexchange: HFS+ invalid number of allocation blocks to recover the disk, we formatted an equally sized disk,
dded
the EFI volume to a temporary file and recovered the partition table (including the main volume) by using the same standard values we got by formatting the empty disk.The EFI of the previously partitioned (empty) disk was saved to a file with:
Repairing the corrupted disk:
The partly "repaired" but corrupted GUID partition table originally looked like this
After removing the EFI partition with:
and rewriting the GUID partition table with
the EFI volume and the main volumes were added with:
The disk and the main volume were verified:
Finally the disk looks like this:
All data was recovered.