Need help deciphering TestDisk results to fix HDD
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.