NTFS recovery - How to find out the first and last sectors of a lost NTFS GPT partition?

Question

So I have this disk where the GPT (GUID partition table) went bad, and was overwritten with a new GPT. This made my NTFS partition inaccessible, but I am sure that the partition itself is still on the drive.

The short explanation:

Beginning: 3tb disk, GUID Partition Table, 2.9tb NTFS partition with small amounts of empty space on either side.

Problem: Driver that can't see whole 3tb disk thinks there is a discrepancy between reported disk size and partition sizes, rewrites GPT to be 700gb, removing NTFS partition from view in the process

Now: Left with a 3tb disk that has a NTFS partition still on the disk, but not accessible since it's not in the partition table

Details can be found in my previous question at

https://unix.stackexchange.com/questions/209388/problems-with-partition-table-on-3tb-ntfs-drive

There, someone suggested that the solution was to create a new GPT with the exact same start and end sectors and type codes for an NTFS partition as the previous partition.

I would like to know how I can figure out what the start and end sectors of the previous partition would be. I believe the drive was formatted NTFS under Windows 7, as an external drive. I have SystemRescueCD, Ubuntu and Xubuntu live USBs, and a separate Windows 7 HDD.

Answer 1

First, fix your driver problem. If you attempt to repair the disk with the bad driver, the best you'll get is access to a portion of the partition. At worst, you'll overwrite critical data in the partition, thus making matters worse.

With the driver problem fixed, you might be able to recover your original partition data with suitable partitioning software. My own GPT fdisk (gdisk) tool can do this; see the GPT fdisk documentation on disk repair for general procedures and suggestions. In brief, the idea is that you may be able to recover the backup partition table (which is stored at the end of the disk) and use it to restore the main partition table. This procedure isn't guaranteed, though; depending on what caused the partition table corruption in the first place, the backup data might or might not be valid on your current disk. Other tools may be able to do what GPT fdisk can do, but I'm not as familiar with them and their capabilities, so I can't make specific suggestions aside from GPT fdisk.

If GPT fdisk can't recover your data, TestDisk may work. This tool scans the disk for signs of "orphaned" filesystems and can add any it finds to your partition table. Thus, in theory, TestDisk should be able to recover your partition(s). In practice, it usually works if the partition's filesystem has not been damaged. TestDisk will sometimes get confused if the disk has been repartitioned, with partitions created at different times starting at different locations, so that there are fragments of old partitions remaining on the disk. It can also take a while to scan the disk -- up to many hours if you do a "deep" scan, which is used to overcome the preceding problem. I'm sure there are similar tools that are more Windows-specific and that may have flashy GUIs, but I don't know what they are or have URLs handy.