Need help deciphering TestDisk results to fix HDD

Question

Background -

While trying to use asr in terminal to copy a failing HDD's contents to empty external HD #1, I facepalm set the target as BACKUP HD #2.

When I hit enter, asr went through it's normal steps, and then hit PSTT 0 100 start restore and hung there for longer than I expected it to. Then I realized that I put the wrong target volume, and terminated the window.

Now, when I plug BACKUP HD #2 into my laptop, it doesn't mount. I can see it in Disk Utility and can run repair on it, but get the following:

"Problems were found with the partition map, that may prevent booting"

Trying to mount it in the terminal fails too.

I have Disk Warrior, and it can see the hard drive (and even shows the name I set for it, whereas Disk Utility shows it as Untitled) but it says the drive is too big.

I have Drive Genius, but it shows up under devices and not volumes, so I can't repair it there either.

I bought Disk Drill, scanned the drive, but it categorized the found files by type - video/pictures/audio/etc and dumped all file name info - they're now file 000001.jpg etc. So I've lost file names and folder structure. I'm so grateful and happy to be able to have my files back, now hoping there's a way to get my structure/names back on the old drive...

After 4 days of scanning with TestDisk, here are the results, but I don't know what to do next. Any ideas?

Thanks!

 TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <[email protected]>
http://www.cgsecurity.org

TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <[email protected]>
http://www.cgsecurity.org

Disk /dev/rdisk1 - 3000 GB / 2794 GiB - 732566645 sectors
     Partition               Start        End    Size in sectors
 P EFI System                     6      76805      76800 [EFI]
 P Mac HFS                   156013  271598000  271441988
>P Mac HFS                280526626  282014439    1487814
 P Mac HFS                288815421  288905227      89807
 P Mac HFS                288931061  289023226      92166
 P Mac HFS                289086265  289190956     104692
 P Mac HFS                290295252  291221714     926463
 P Mac HFS                486080570  486424828     344259
 P Mac HFS                489985809  490029384      43576
 P Mac HFS                701675873  709084595    7408723

Structure: Ok.  Use Up/Down Arrow keys to select partition.
Use Left/Right Arrow keys to CHANGE partition characteristics:
                P=Primary  D=Deleted
Keys A: add partition, L: load backup, T: change type,
     Enter: to continue
HFSX blocksize=4096, 6094 MB / 5811 MiB

Answer 1

The TestDisk results for OS X disks are often misleading or even wrong because the algorithm misinterprets special hidden volume content. AFAIK it tries to detect special empty blocks (2) followed by the occurrence of the string HFSJ in the third block - which marks the beginning of a HFSJ volume. A similar sequence is used to detect the last blocks of a volume. Such 1536 Byte "blocks" are more frequent than TestDisk can handle.

I prefer a different approach:

External disks partitioned by Disk Utility to one (visible) HFS+ volume usually have a typical partition scheme:

depending on the the Device Block Size (either 512 B or 4096 B) and the total size of the disk they either contain a 200 MiB or 300 MiB EFI partition as first partition after the partition table, then the main volume and finally a 134.2 MiB partition or free space of the same size. The last blocks are occupied by the second ("backup") partition table.

The standard Apple GUID partition scheme of a 512 B disk looks like this:

                0           1         PMBR
                1           1         Pri GPT header
                2          32         Pri GPT table
               34           6         
               40      409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
           409640  part2-size      2  GPT part - partition type
part2-size+409640      262144      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
    total_size-40           7         
    total_size-33          32         Sec GPT table
     total_size-1           1         Sec GPT header

part2-size usually is: total-size - 671824 in 512 B-blocks. If partition 3 is missing the last three lines look like this:

total_size-262190      262151         
    total_size-33          32         Sec GPT table
     total_size-1           1         Sec GPT header

The standard Apple GUID partition scheme of a 4096 B disk looks like this:

               0           1         PMBR
               1           1         Pri GPT header
               2           4         Pri GPT table
               6       76800      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
           76806  part2-size      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
total_size-32773       32768         
    total_size-5           4         Sec GPT table
    total_size-1           1         Sec GPT header

part2-size usually is: total-size - 109579 in 4096 B-blocks.

512 B disks may also have a 614400 blocks(512) EFI partiton (partition 1) or 4096 B disks may have a 51200 blocks(4096) EFI partition - both can be found less frequently than the other way round though. The size of the main partition is reduced or enlarged respectively.

---

Since gpt only writes in the first and the second partition table (and doesn't overwrite volume content!) you may test now which partition sizes may fit.

The basic gpt commands are the following:

• show the partition table:

  sudo gpt -r show diskX 
  

• add a partition:

  sudo gpt add -i (i) -b (block-nr) -s (blocks) -t (GUID) diskX
  

  with i: index number, b: start block, s: size, t: partition type

• remove a partition:

  sudo gpt remove -i (i) diskX
  

• destroy partition table:

  sudo gpt destroy diskX
  

• create a new partition table:

  sudo gpt create -f diskX
  

---

Repairing your disk:

• detach any external disk, thumb drive etc except the corrupted one.
• Open Terminal.app and enter diskutil list to get an overview. In the output you will get the disk identifier of the external disk (e.g. disk2; below I assume it's disk2, your disk identifier may differ!)

• get the device block size:

  diskutil info disk2 | grep "Device Block Size"
  

• get the partition table of the disk:

  sudo gpt -r show disk2
  

• Unmount the disk:

  diskutil umountDisk disk2
  

• if you find partitions remove them all with e.g. sudo gpt remove -i 2 disk2, sudo gpt remove -i 3 disk2 and sudo gpt remove -i 1 disk2. If no partition table is found create a new one.

• examining your disk's properties (probably a 4096 B disk) I would try the following now:

  sudo gpt add -i 1 -b 6 -s 51200 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B disk2
  sudo gpt add -i 2 -b 51206 -s 732482666 -t 48465300-0000-11AA-AA11-00306543ECAC disk2
  

  then verify a potential volume with

  diskutil verifyVolume disk2s2
  

  or if this fails remove the partitions again with sudo gpt remove -i 2 disk2 and sudo gpt remove -i 1 disk2 and choose a different EFI partition size:

  sudo gpt add -i 1 -b 6 -s 76800 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B disk2
  sudo gpt add -i 2 -b 76806 -s 732457066 -t 48465300-0000-11AA-AA11-00306543ECAC disk2
  

  then verify a potential volume with

  diskutil verifyVolume disk2s2
  

---

A different method to find relevant partition boundaries are outlined in this answer: how to fix GUID hard drive corrupted to MBR and several other answers.

In principle, it's similar to the TestDisk method but with some (human) interpretation of detectable/detected characteristic volume structures. Therefore it's not automated and slower.

---

If your asr task has overwritten important parts of the previous main volume, it can't be salvaged.