0

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.

Improve this question
2
  • If NTFS or FAT32, you have to use chkdsk from Windows. But you seem to have restored FAT32 partitions? NTFSfix really only turns on chkdsk needed flag if NTFS. You cannot run fsck for ext family of formats on NTFS. But if FAT32 correct: askubuntu.com/questions/862724/grub2-failed-to-install/… If you recovered photorec photos you can easily rename them with Exif meta-data. cgsecurity.org/wiki/After_Using_PhotoRec Only if testdisk's deeper search showed full file names can you restore original. Some have posted that Windows tools work better on NTFS. Commented Jul 16, 2021 at 14:59
  • "does not start on physical sector boundary" = bad news for disk I/O performance since your physical blocks are 4096 bytes, but you have 512 byte logical chunks. Commented Jul 17, 2021 at 0:07

2 Answers 2

Reset to default
0

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!

Improve this answer
0

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.

Improve this answer
1
  • Thank you for providing such a thorough and structured response. I had originally copied an image of the corrupted disk before making any changes, but ultimately it wasn't particularly useful. A complicating factor is that the disk is about five years old and probably had changed made to it by both Windows and Linux based tools. Commented Jul 20, 2021 at 6:15

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.