Partition map rebuild

Question

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:

score 3 · Accepted Answer · edited Apr 13 '17 at 12:45

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:

diskutil unmountDisk /dev/disk2
dd if=/dev/disk2s1 of=/Users/user/Desktop/disk2s1.raw

Repairing the corrupted disk:

The partly "repaired" but corrupted GUID partition table originally looked like this

sudo gpt -r show disk2 
    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

After removing the EFI partition with:

sudo gpt remove -i 1 /dev/disk2

and rewriting the GUID partition table with

sudo gpt destroy /dev/disk2
sudo gpt create /dev/disk2

the EFI volume and the main volumes were added with:

sudo gpt add -b 6 -i 1 -s 76800 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B /dev/disk2
sudo dd if=/Users/user/Desktop/disk2s1.raw of=/dev/disk2s1
sudo gpt add -b 76806 -i 2 -s 244081066 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk2

The disk and the main volume were verified:

diskutil verifyDisk /dev/disk2
diskutil verifyVolume /dev/disk2s2

Finally the disk looks like this:

sudo gpt -r show disk2 
    start        size  index  contents
        0           1         PMBR
        1           1         Pri GPT header
        2           4         Pri GPT table
        6       76800      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
    76806   244081066      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
244157872       32768
244190640           4         Sec  GPT  table
244190644           1         Sec  GPT header

All data was recovered.

I have a disk with similar issues, but I do not understand where you get the volume value 48465300-0000-11AA - AA11-00306543ECAC — , Dec 28 '15 at 07:38
@Gush Please ask a separate (new) question instead of editing deleted non-answering answers! You may refer to the question and the answer here. — klanomath, Dec 29 '15 at 00:57

score 0 · Answer 2 · answered Dec 16 '15 at 22:54

If this is valuable data, I would suggest going to a drive recovery service. It may be as little as $500 depending on the damage. Some places will give you an estimate for free. You can ask around on the HDD Guru forum for a recovery service in your area.

If you still want to do this yourself and aren't concerned about losing your data, I would attempt recover as many sectors as possible with ddrescue and write it to an image file. i.e.

sudo ddrescue /dev/diskXsX /path/to/disk_image /path/to/log_file

You can get ddrescue with MacPorts or a similar package manager. Keep in mind that depending on the damage done to your disk, the longer you attempt to read from it with something like ddrescue, the more damage your disk may incur.

After you've recovered as much data as you can with ddrescue then attempt to fix the filesystem on the recovered image or scrape it for files.

Partition map rebuild

2 Answers2

Linked