Need help deciphering TestDisk results to fix HDD
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
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) diskXwith 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 listto 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 disk2andsudo 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 disk2then verify a potential volume with
diskutil verifyVolume disk2s2or if this fails remove the partitions again with
sudo gpt remove -i 2 disk2andsudo gpt remove -i 1 disk2and 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 disk2then 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.