Recover Corrupt SSHD

Question

I had an old 2011 13" MPB with a 250 GB Samsung Evo 840 SSD and, using the OWC expansion bay mod, a 1 TB Seagate SSHD. The SSD was the boot drive and the SSHD was just for Time Machine backups, file storage, and a boot camp partition. Unfortunately, I spilled water on that Mac and it subsequently died. Yesterday I finally got around to getting a new Mac. I now have a 2013 15" Retina model with 500 GB flash storage. I used Migration Assistant to transfer all my files from the SSD as it was the boot drive and the drive with my user account on it. However, after that I hooked up the 1 TB SSHD but the Mac gave me this error:

"The disk you inserted was not readable by this computer"

So I opened Disk Utility and ran First Aid, but to no avail.

Usually I am very technical and can fix almost anything myself but this time I think I am over my head. Please help me resolve this so I can get my files from the drive. Originally the drive had three partitions: 2 of them were either GUID or HFS+ (I don't recall... I did use rEFIt if that matters) and one was NTFS (my Boot Camp partition).

Here is a screenshot what Disk Utility reported:

Output of diskutil list:

/dev/disk0 (internal, physical):
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      GUID_partition_scheme                        *500.3 GB   disk0
       1:                        EFI EFI                     209.7 MB   disk0s1  
       2:          Apple_CoreStorage Macintosh SSD           499.4 GB   disk0s2  
       3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3  

/dev/disk1 (internal, virtual): 
       #:                       TYPE NAME                    SIZE       IDENTIFIER   
       0:                            Macintosh SSD          +499.0 GB   disk1  
                                 Logical Volume on disk0s2  
                                 F0B49497-24EC-4A50-818C-A7897F573B5D  
                                 Unencrypted  

/dev/disk2 (external, physical):  
       #:                       TYPE NAME                    SIZE       IDENTIFIER  
       0:     FDisk_partition_scheme                        *1.0 TB     disk2  
       1:                       0xEE                         1.7 GB     disk2s1  
       2:                  Apple_HFS                         998.5 GB   disk2s2  

Jons MacBook Pro:~ Jonathan$ gpt -r show disk2  
gpt show: unable to open device 'disk2': Permission denied  

Output of sudo gpt -r show disk2:

gpt show: disk2: Suspicious MBR at sector 0  
gpt show: error: bogus map  
gpt show: unable to open device 'disk2': No such file or directory  

Output of sudo fdisk /dev/disk2:

Disk: /dev/disk2    geometry: 15200/255/63 [244190646 sectors]
Sector size: 4096 bytes
Signature: 0xAA55
         Starting       Ending
 #: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
 1: EE 1023 254  63 - 1023 254  63 [         1 -     409639] <Unknown ID>
 2: AF 1023 254  63 - 1023 254  63 [    409640 - 1175509584] HFS+        
 3: AF 1023 254  63 - 1023 254  63 [1176181368 -  292707720] HFS+        
*4: 07 1023 254  63 - 1023 254  63 [1469151232 -  484372480] HPFS/QNX/AUX

Answer 1

Your SSHD is not corrupt in the sense that you lost any data but parts of the GUID partition table can't be read properly.

The SSHD either lost its GUID partition table or the USB/SATA controller in the external case reports a device block size of 4096 Bytes while your disk has a block size of 512 Bytes. In case of the latter you have to use another external case to mount the SSHD.

A common 512 Bytes Device Block Size GUID compared to a 4096 Bytes Device Block Size GUID differs like this:

             512 size number  4096 size number ("in block(512) numbers")
pMBR                1      0          1      0         0-7
Pri GPT header      1      1          1      1         8-15
Pri GPT table      32   2-33          4    2-5        16-47
1st "used" block          40                 6        48

If you mount a "512 Bytes device" in a "4096 Bytes case", the system expects the primary GPT header in block(4096) 1 (which "translates" to blocks(512) 8-15) and the primary GPT table in the blocks(4096) 2-5 (which "translates" to blocks(512) 16-47). This will fail because the primary header of the disk(512) is in block(512) 1 and the primary table starts at block(512) 2.

It's obvious that you can't rewrite a GPT(512) to a GPT(4096) because the last block of the GPT(4096) table would overlap the first useable block of the GPT(512) disk.

---

Try the following to restore the GUID partition table:

• Open Terminal.app and enter the following commands to get an overview and fundamental data to recover previous partition tables if the following commands fail:

  disktutil list
  diskutil info diskX | grep "Device Block Size" # with diskX: the disk identifier of the SSHD
  

  If the command returns: Device Block Size: 512 Bytes continue, if 4096 Bytes are reported stop here and get a 512 Byte-capable external case:

  sudo gpt -r show diskX # with diskX: the disk identifier of the SSHD
  sudo fdisk /dev/diskX # with diskX: the disk identifier of the SSHD
  

  In your case diskX: disk2

• Unmount the external disk (just to be sure that it is unmounted). Below I assume diskX is disk2:

  diskutil umountDisk disk2
  sudo gpt destroy disk2
  sudo gpt create -f disk2
  

  Now enter sudo gpt -r show disk2 if a new GUID partition table was created. It should look like this:

         start         size  index  contents
              0            1         PMBR
              1            1         Pri GPT header
              2           32         Pri GPT table
             34   1953525102
     1953525135           32         Sec GPT table
     1953525167            1         Sec GPT header
  

  If you get an error or no GUID pt was created you have to force-destroy the MBR:

  sudo if=/dev/zero of=/dev/disk2 bs=512 count=1
  

  The command directly overwrites the first block of disk2 (the MBR of the disk) with zeros. If entered wrong (e.g without the "count=1" or the wrong disk identifer), it overwrites the whole disk. The command above should completed after milliseconds. If not, enter ctrlC to stop the command immediately.

  Then repeat:

  sudo gpt create -f disk2
  

  Recheck if it was successful now.

• Add the partition one by one in the GUID partition table with gpt:

  To add an partition with gpt use the following command

  sudo gpt -i index_number -b first_block -s size -t partiton_type diskX
  

  with index_number: ~the partition number; first_block and size in blocks (either 512 or 4096 blocks) and partiton_type: a special GUID

  In your case that's:

  sudo gpt -i 1 40 -s 409600 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B disk2
  sudo gpt -i 2 409640 -s 1175509584 -t 48465300-0000-11AA-AA11-00306543ECAC disk2
  diskutil umountDisk disk2
  sudo gpt -i 3 1176181368 -s 292707720 -t 48465300-0000-11AA-AA11-00306543ECAC disk2
  diskutil umountDisk disk2
  sudo gpt -i 4 1469151232 -s 484372480 -t EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 disk2
  

• Now the "lost" volumes should reappear. Check the disk and the volumes with diskutil verifyDisk /dev/disk2, diskutil verifyVolume /dev/disk2s2 and diskutil verifyVolume /dev/disk2s3.
• Repair everything if necessary - but report back before starting the repair.

---

If you don't have an external case(512) but a second empty disk with at least 1 TB you should be able to recover each partition on disk2 by dd'ing each to a separate file (e.g sudo dd if=dev/disk2 of=/Volumes/Disk3/efi.rawdevice bs=512 skip=40 count=409600 to copy the EFI partition) on the empty disk. After dd'ing all four partitions to an external volume, repartition disk2 properly and restore each of the four rawdevice files to its "new" partition.

---

The command gpt usually only writes to the first 34 and last 33 blocks and fdisk only to the first block on a disk with a block size of 512 Bytes. This will not destroy or modify your data. So everything you do is reversible.