Recovering an entire partition that has been somewhat formatted (I seriously messed up an external HD's filesystem)
You should be able to restore at least the boundaries of the old NTFS volume:

Windows (like OS X) uses some default partition schemes to partition and format a disk.

An MBR/NTFS disk usually has an MBR in the first block (block0). The first partition usually starts at the 1 MB boundary (that's block2048) with a special block - the NTFS Boot Sector - and ends with a special block. Both blocks start with EB 52 90 4E 54 46 53 20 (hex) or ∂RENTFS(x20). The last 4096 blocks (2 MiB) are empty space usually.

Depending on how much was written while creating ("erasing") the new main HFS+ volume (usually about 120 - 160 MB after the process finished) the success of a data recovery may vary.



Detach any external drive except the broken one!

To recover the old NTFS volume boundaries you have to delete the GUID partition table and restore an MBR partition scheme:

To remove the GUIDpt, first open Terminal.app and get an overview (below I assume the disk identifier of the falsely formatted disk is disk2):

diskutil list
sudo gpt -r show disk2


The result is similar to the one below (your total size - here 1953525760 blocks and the main volume - here 1952853936 blocks - may differ slightly):

         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 1952853936      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
1953263576     262151         
1953525727         32         Sec GPT table
1953525759          1         Sec GPT header


Remove the GUIDpt:

diskutil umountDisk disk2
sudo gpt destroy disk2 
dd if=/dev/zero of=/dev/disk2 bs=512 count=1


Search the disk for the string ∂RENTFS(x20) in the last sectors of the disk:

hexdump -s 930g /dev/rdisk2  | grep "eb 52 90 4e 54 46 53 20"


-s: Skip offset bytes from the beginning of the input. The size is KiB/MiB/GiB. In my example the disk has a size of 931.51 GiB, so I searched the last 1.51 Gib only.

The result is e8e0bffe00 eb 52 90 4e 54 46 53 20 20 20 20 00 02 08 00 00 with e8e0bffe00 being the offset in hex.
Converted with a hex2dec service this means an offset of 1000203091456 (dividing this by 512, the result is equal to block 1953521663).

Since this block is the last one in the previous volume you can determine the old volume size: 1953521663 (last block) - 2048 (probable start block) + 1 (counting starts with 0). The result has to be divisible by 8!

You may also check the first blocks of the disk with:

hexdump /dev/rdisk2  | grep "eb 52 90 4e 54 46 53 20"


You should get at least one line like this: 800 eb 52 90 4e 54 46 53 20 20 20 20 00 02 08 00 00. This is the NTFS Boot Sector at block 2048 - the 1 MB boundary - since these blocks are usually not erased by Disk Utility. Enter ctrlC to stop hexdump.

Now having the first block and the last block of the NTFS volume you should be able to restore the old MBR partition with fdisk:

fdisk -e /dev/disk2
Would you like to initialize the partition table? [y] y
fdisk:*1&gt; auto dos
fdisk:*1&gt; edit 1
     Starting       Ending
#: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
*1: 0C    0   1   1 - 1023 254  63 [        63 - 1953525697] Win95 FAT32L
Partition id ('0' to disable)  [0 - FF]: [C] (? for help) 07
Do you wish to edit in CHS mode? [n] n
Partition offset [0 - 1953525760]: [63] 2048 #probable start of the NTFS volume
Partition size [1 - 1953523712]: [1953523712] 1953519616 #use the probable size of YOUR NTFS volume found previously here.
fdisk:*1&gt; write
Writing MBR at offset 0.
fdisk: 1&gt; q




Now you may be lucky and the NTFS volume just pops up or you have to use a data recovery tool.