Recovering an entire partition that has been somewhat formatted (I seriously messed up an external HD’s filesystem)

command linedata-recoveryexternal-diskpartitionunix

I have an embarrassing but very urgent problem. A friend of mine asked me to set up their new external HD for both Time Machine and file storage, and to transfer over files from their old HD. I started to partition the new drive using Disk Utility, but the partition option was greyed out. The entire disk was formatted as exFat, so I thought to reformat it as HFS+. I began to do so with diskUtil: diskUtil erasedisk hfs+ External /dev/disk2 (Note: this is on a Macbook Pro running El Capitan)

However, I mistyped. The new drive was not disk2, it was disk3–I had started to erase the old disk instead, which has important data in it. I realized my problem in an instant and ^C'd my way out of there, but the damage was done. Here's the sitch:

  • Terminal output says:

    Starting erase on disk2
Unmounting disk
diskutil:interrupted
$ diskUtil list
...
/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk2
   1:                        EFI EFI                     209.7 MB   disk2s1
   2:                  Apple_HFS                         999.8 GB   disk2s2

  • As you can see, OSX recognizes the drive as GPT and the partition as HFS+. However, the drive will not show up in Finder.

  • Windows (10) recognizes that I have an external HD plugged in, but nothing shows under "Volumes" when I view its device in Device Manager.
  • Linux (Arch) recognizes the drive and the partition, just like OSX. I tried running ntfsfix, but to no avail. (It gave me a warning that said something about being unable to fix it and to try using chkdsk).
  • I am not 100% certain what the state of this HD was before I half-formatted it. It was first used and formatted on a cheap Windows laptop when Vista was the newest Windows OS, so I would think that it was NTFS on an MBR scheme before I violated it. (Perhaps I'm wrong and someone knows better, but that's what I'm led to believe).

Anyways, here I am. I need to recover about 700GB of data, perhaps NTFS/MBR, on a drive that thinks it's HFS+/GPT. All of the data has got to be there, more or less at least, but I need help accessing it. If you have any insight or knowledge that could help me out, I would truly appreciate it.

(Lastly, I've downloaded and installed some data recovery software from Easeus. It's running a "scan" on the drive, and I suspect it'll fix my problem if I dish over $90 or so. This is just a last resort, though. I'd really rather not have this headache become an expensive one, and since it's picking a lot of data, I know there's gotta be a way to solve this with some elbow grease.)

Best Answer

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> auto dos
fdisk:*1> 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> write
Writing MBR at offset 0.
fdisk: 1> q

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

Related Question