Hard Drive – What Is the Likely NTFS State?

data-recoveryhard driventfs

I've broken an external drive containing photos which I'd like to recover. It's an NTFS formatted drive. I've done some preliminary investigation but I don't understand what I'm seeing. I'll provide some context, some observations and some conclusions and right now I'm just looking for information – have I made sensible conclusions?

Context
It was a while ago but I think what happened was:

  1. I formatted it on Windows with one NTFS partition and then copied photos to it
  2. I plugged it into a Raspberry Pi running Raspbian
  3. The drive seemed to power cycle continuously (perhaps the RPi couldn't power that along with another external and keyboard + mouse via USB?)
  4. I presumed whatever damaged would be done had been done and unplugged the drive.

Observations
Here's its state as reported by various processes:

  • It appears as /dev/sda when plugged into a Linux system (the same RPi without another disk).
  • It doesn't appear with a drive letter in Windows although it does show as a raw disk in Disk Management.
  • EaseUS can show the file structure (directories and file names) after doing a scan so I think the errors are soft errors rather than physical drive failure.

Now, I want to image the disk before fiddling with it anymore. However, it's a 1TB disk and I don't have the space for a full sector by sector copy. So I want to inspect particular parts of the disk and try a more targeted approach. I accept that poking around where I don't understand could make things worse but that's why I'm looking here for further information.

Conclusions
This Wikipedia page on NTFS seems to show that the first 500 bytes or so is the NTFS Boot Sector and therein is data which describes the rest of the NTFS file system. Since EaseUS is able to figure out the file structure which is still physically on there, I think much of the NTFS data is still physically there too (i.e. data about the file structure within NTFS, not just the files themselves). Is that a correct assumption?

So, whatever information is required to mount the drive is corrupted somehow but, suppose it could be mounted, then the file structure description is still present somewhere. But where in the NTFS structure would this be? In the Master File Table? Is that right?

So, if much of the NTFS data is still there, it should be in the first 500 bytes, right?

More Observation
I ran ddrescue count=100 if=/dev/sda =of=~/myDisk.img conv=noerror but the output file ~/myDisk.img was 51200 bytes of 0x00. ddrescue is reporting many "Inut/output error" warnings as it tries to read the sectors.

I also ran ddrescue count=100 if=/dev/sda =of=~/myDisk.img conv=noerror skip=1G as a blind guess that my data would be near the start of the drive but that was empty too (but no "Input/output error" warnings).

When I ran ddrescue count=100 if=/dev/sda =of=~/myDisk.img conv=noerror skip=2G then ddrescue told me that "skip" was an invalid argument. I think it was trying to say that "2G" was an invalid value for the skip argument but I don't know why that's the case on a 1TB drive.

Final Question
Have I misunderstood something basic about NTFS or is the NTFS Boot Sector really empty? If the Boot Sector really is empty, how is a tool like EaseUS able to rebuild the file structure?

Best Answer

Conclusions This Wikipedia page on NTFS seems to show that the first 500 bytes or so is the NTFS Boot Sector and therein is data which describes the rest of the NTFS file system. Since EaseUS is able to figure out the file structure which is still physically on there, I think much of the NTFS data is still physically there too (i.e. data about the file structure within NTFS, not just the files themselves). Is that a correct assumption?

Yes, except the boot sector only has a pointer to the $MFT file, and that file describes everything else about the file system. Practically all NTFS metadata is stored in the form of invisible files with $ names (you can find a table on the same article).

More Observation I ran ddrescue count=100 ...

The description is very odd, because although you say you used 'ddrescue' the rest of your command (and its results) look very much like you actually used plain 'dd'. Despite the similar names those are actually very different tools.

The 'ddrescue' command has a different syntax from 'dd' (and works differently overall – it is designed to copy from disks which have many bad sectors). As in Attie's example, you should have used:

ddrescue /dev/sda ~/mydisk.img ~/mydisk.map --size=2G

(The map file allows you to stop and resume a copy, as well as use ddrescueview to graphically see which disk areas are bad and couldn't be copied.)

When I ran ddrescue count=100 if=/dev/sda =of=~/myDisk.img conv=noerror skip=2G then ddrescue told me that "skip" was an invalid argument. I think it was trying to say that "2G" was an invalid value for the skip argument but I don't know why that's the case on a 1TB drive.

In dd (not ddrescue!), parameters such as 'count' and 'skip' always take a number of blocks, not bytes. So "2G" does not mean two gigabytes, it means 2147483648 blocks of 512 bytes (or whatever custom size was specified using [i]bs=).

Additionally, dd uses binary size units (where K=1024) and manufacturers sell their disks using decimal units (where k=1000).

With the default 512-byte block size, "skip=2G" actually means exactly 1 TiB (1099511627776 bytes), and that's more than your disk – most HDDs are only 1 TB (1000000000000 bytes or just a bit over 931 GiB).

Final Question Have I misunderstood something basic about NTFS or is the NTFS Boot Sector really empty? If the Boot Sector really is empty, how is a tool like EaseUS able to rebuild the file structure?

The NTFS boot sector only stores a few very basic parameters about the filesystem, such as cluster size, or the start location of the $MFT file – a recovery tool could easily guess them as there are only a few typical cluster sizes, and $MFT is almost always placed at the same location.

(The majority of the boot sector's data has nothing to do with the file system itself, it really only stores boot code which is used to start the OS. Many file systems reserve the first few sectors for this purpose, due to the way PC BIOS boot process works.

On BIOS systems only one partition – the hidden "system" partition in Vista or later, or the C: partition in XP or older – needs to have a working boot sector. On UEFI systems the boot mechanism is different and boot sectors aren't used for anything at all.)

Related Question