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.