1

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?

3
  • First things first, plug it into a proper PC that can definitely deliver the required power, don't use the Pi. I wouldn't have expected a brownout condition to cause issues like this, but perhaps I've been lucky in the past. 0x00 would correlate with an I/O error (it's not valid data, but a hole, as ddrescue's log would convey). The count=n and seek=n arguments are for dd, not ddrescue. The skip=1G would be 512 * 1 * 1024^3 = 512GiB and skip=2G would be 512 * 2 * 1024^3 = 1TiB (i.e: multiplying the block size / bs, not counting in bytes - use iflag=skip_bytes for that)
    – Attie
    Commented Jul 8, 2020 at 22:51
  • 1
    Is the external disk a DIY assembly, or off-the-shelf? Can you connect your external drive to a Linux PC, not a Pi? (even if you use a live environment). You're right to want to make an image first, and if you have the storage I would strongly recommend that you do so. Use ddrescue (not dd), and make sure you use a mapfile. A simple ddrescue ${disk} image.img image.map would suffice for the first pass.
    – Attie
    Commented Jul 8, 2020 at 23:05
  • Mount the drive as secondary then use this software to recover files>>>>runtime.org/data-recovery-software.htm
    – Moab
    Commented Jul 8, 2020 at 23:19

1 Answer 1

2

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.)

1
  • Great, thanks for the really helpful feedback. You were right, I was using dd instead of ddrescue - I got myself confused. And the info about me confusing my intended 2G bytes for 2G blocks is obviously helpful. I have a followup question about the location of the MFT ("almost always in the same location") but I'll try some googling and research before starting a new question. Thanks again for simply answering the questions! Commented Jul 9, 2020 at 20:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .