Recover Formatted NTFS Partion

Question

Please don't mark this as duplicate - I have read many other questions and proposed answers and can't seem to get them to work.

I have 3 1TB hard drives, 2 SSDs and 1 HDD. I accidentally deleted the partition table and possibly formatted the HDD whilst trying to install Windows 10 on one of the SSDs.

I'm trying to recover my data from the HDD, it has a lot of photos from about 10 years ago. HHD is just a data disk, although it briefly had a Linux installation on it in 2018.

Disk Model: ST1000DM003-1SB1

I have been trying to recover the photos using TestDisk to mixed results. I have been unable to restore the partition table, however I know the data is still on the disk because I was able to extract it using Photorec. The only problem is that photo rec has removed all structuring and order on approx 8K photos.

The results from TestDisk are as follows:

Disk /dev/sda - 1000 GB / 931 GiB - CHS 121601 255 63
Current partition structure:
     Partition                  Start        End    Size in sectors

 1 * FAT32                    0   1  1   242 254 63    3903732 [RECOVERY]
 2 P FAT32 LBA              243   0  1  7401 254 63  115009335 [NO NAME]
 3 E extended LBA          7402   0  1 102927 254 63 1534625190
 5 L FAT32 LBA             7402   1  1 12160 254 63   76453272 [NO NAME]
   X extended             102927  97  1 102927 232 38       8543
Invalid FAT boot sector
 6 L FAT16 <32M           102927  98 62 102927 232 38       8419
 6 L FAT16 <32M           102927  98 62 102927 232 38       8419

Running fdisk -l returns:

Disk /dev/sda: 931.53 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: ST1000DM003-1SB1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x17556621

Device     Boot      Start        End    Sectors   Size Id Type
/dev/sda1  *            63    3903794    3903732   1.9G  b W95 FAT32
/dev/sda2          3903795  118913129  115009335  54.9G  c W95 FAT32 (LBA)
/dev/sda3        118913130 1653538319 1534625190 731.8G  f W95 Ext'd (LBA)
/dev/sda5        118913193  195366464   76453272  36.5G  c W95 FAT32 (LBA)
/dev/sda6       1653528490 1653536908       8419   4.1M  4 FAT16 <32M

Partition 1 does not start on physical sector boundary.
Partition 2 does not start on physical sector boundary.
Partition 3 does not start on physical sector boundary.
Partition 5 does not start on physical sector boundary.
Partition 6 does not start on physical sector boundary.

Trying to mount returns:

billy@billy-Mint:~$ ntfsfix -b /dev/sda3
Mounting volume... Error opening read-only '/dev/sda3': Permission denied
FAILED
Attempting to correct errors... Error opening read-only '/dev/sda3': Permission denied
FAILED
Failed to startup volume: Permission denied
Error opening '/dev/sda3': Read-only file system
Volume is corrupt. You should run chkdsk.

sudo fsck /dev/sda3 yielded the following:

fsck.ext2: Attempt to read block from filesystem resulted in short read while trying to open /dev/sda3 Could this be a zero-length partition?

Any help would be greatly appreciated. I'm stumped about how to proceed.

Answer 1

Just to bring this full circle for anyone who find this in the future. I spoke to a software engineer at my work, and he advised that I had already achieved the best outcome possible. I.e. recovering the data with photorec was the best I could hope for, that I wouldn't be able to recover the data within the folder structure, as the folder structure had been lost when I deleted the partition table. Hope that helps!

Answer 2

A MBR-partitioned disk has a hard maximum of four primary partitions. To get around this limit, you can use one of the primary partitions as an extended partition: a sort of container for further ("logical") partitions.

In your case, sda3 is an extended partition that contains logical partitions sda5 and sda6. The last primary partition slot sda4 is unused.

The extended partition only ever contains other partitions: it is never directly usable as a partition by itself. This is a quirk of the MBR partitioning scheme, that has existed from the days of the first hard-disk-equipped PC in the 1980s.

As a result, trying to run ntfsfix or any other repair tool on your /dev/sda3 does not make sense. If that part of the disk had contained any recognizable remains of a NTFS filesystem, I'm sure testdisk would have reported it and included it in the partition structure to be recovered.

As it is, either there was no NTFS partition at all (as the recovered partition table looks like something Windows 9x/ME would have used: those OSs did not support NTFS at all)... or the beginning of that partition was so thoroughly overwritten that it was unrecognizable to testdisk, in which case I would not expect ntfsfix to be able to achieve anything useful either.

From man ntfsfix:

ntfsfix is a utility that fixes some common NTFS problems. ntfsfix is NOT a Linux version of chkdsk. It only repairs some fundamental NTFS inconsistencies, resets the NTFS journal file and schedules an NTFS consistency check for the first boot into Windows.

Assuming that there actually was a NTFS partition on the disk, I agree with your software engineer's assessment: you already got the best possible outcome.

But if that's not true, and the recovered partition table seems correct to you, then you should leave sda3 alone and proceed to attempting to access (and if necessary, recover) sda5 and sda6.

The filesystem repair tools should be chosen according to the filesystem expected to be on the partition: trying to run tools intended for a NTFS or an ext2 filesystem (ntfsfix and fsck.ext2 respectively) will achieve nothing useful if the actual filesystem type is e.g. FAT32, and in fact could corrupt the remaining data further by making inappropriate changes based on false assumptions.

On a recovery situation like this, you should explicitly select the correct tool for the filesystem type, instead of running the generic fsck command. For sda5 and sda6, fsck.vfat might be the correct tool if the partition types are correct in the recovered partition table.

The Partition X does not start on physical sector boundary. can be ignored: since the starting sector of the first partition is 63 and not 1024, this disk has clearly been partitioned with a legacy OS that followed the old DOS-era conventions on starting a partition ideally at the beginning of a cylinder or track according to the legacy C/H/S geometry, and that results in partitions that are not strictly "optimal" for modern disks.

On a disk that is modern enough to use a physical sector size of 4096 bytes, the reported C/H/S geometry is just a fiction that is maintained because legacy OSs expect it: it has no relation to the actual layout of the data blocks on the disk.