Linux Data Recovery – Using ddrescue to Retrieve Data Off a Failing NTFS Disk

data-recoveryddrescuelinuxntfs

I am attempting to save some user data of a disk that has failed in a Window 8 computer. I've removed the HDD that was unable to be read by the Windows 8 laptop, plugged into my OS X machine which can see the partitions but cannot mount them. (ntfs-3g cannot either).

diskutil list shows:

/dev/disk8 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk8
   1:                        EFI ESP                     524.3 MB   disk8s1
   2: 786BA1D3-6BAF-4D9G-B621-461EB71A4965               41.9 MB    disk8s2
   3:         Microsoft Reserved                         134.2 MB   disk8s3
   4:           Windows Recovery                         513.8 MB   disk8s4
   5:       Microsoft Basic Data                         985.0 GB   disk8s5
   6:           Windows Recovery                         471.9 MB   disk8s6
   7:           Windows Recovery                         367.0 MB   disk8s7
   8:           Windows Recovery                         13.2 GB    disk8s8

I am using ddrescue to try to recover the contents of the HDD … so I am currently using the command:

sudo ddrescue -n /dev/rdisk8s5 ./backup.dmg mapfile

based on the assumption that the actual user data is in partition #5…

So far, after a few days, the current output of ddrescue looks like:

GNU ddrescue 1.20
Press Ctrl-C to interrupt
Initial status (read from mapfile)
rescued:   126523 MB,  errsize:       0 B,  errors:       0

Current status
rescued:   261066 MB,   errsize:         0 B,    current rate:  19202 kB/s
   ipos:   456274 MB,    errors:         0,      average rate:   1568 kB/s
   opos:   456274 MB,  run time: 23h 49m 38s,  remaining time:         n/a
time since last successful read:          0s

The runtime will be off as I have ctrl-c a couple times, once to try file on the .dmg to see if it could determine anything (nope).

From what I can tell, it's inflating the dmg to the relative size of the ipos and opos but from what I understand, the true size of data recovered is the rescued amount.

One thing I notice is that while the average rate is 1568kB/s, it only seems to read every 1min-2min for about 5-10s.

From the above information, I am currently waiting for it to finish this pass (estimating, based on the size of the dmg ( ipos/opos size) it should be a total of ~ 100 hrs, but not sure if I should double that due to the rescued size being half that (do I need twice the disk space to save to?)

Anyone with experience in disk recovery, I have the following questions —

  1. how's this looking? I see no errors but the disk cannot be read by it's own PC, and the mac cannot mount it either so I am pessimistic about recovering data.

  2. once i'm "done" … what will be needed to be done to access the data being saved in the .dmg — Will Windows 8 encryption be something I run into?

  3. do I need 2x the disk space for the DMG that's being saved? Since rescued size is half the dmg and ipos/opos. or is the drive in such dire state that it's only recovering half of everything.

I don't think the used drive space is anywhere near 1 TB of user data…

Any other suggestions would be hugely appreciated.

Best Answer

Disclaimer: I am the developer of RecuperaBit. This answer is a summary of this answer of mine, mixed with feedback by OP.

Your ddrescue command is cloning only the fifth partition (/dev/rdisk8s5) which is good if you are sure that the partition table is correct. However, if you have enough space I strongly suggest that you clone the whole drive.

once to try file on the .dmg

Keep in mind that ddrescue makes raw bitstream copies of drives. That file is not a DMG file, no matter how you call it. Usually, you would use the .img extension or sometimes .dd.

the disk cannot be read by it's own PC, and the mac cannot mount it either so I am pessimistic about recovering data

You won't get a working partition back, for sure. But it is possible to recover the parts of data that were not damaged, even if the NTFS structures are partially damaged.

If the drive is only slightly ruined you might try testdisk, however the fact that file did not detect a NTFS signature suggests that the situation is worse.

what will be needed to be done to access the data being saved

You can use RecuperaBit, which is an open source software for forensic NTFS reconstruction. The algorithm it uses performs a bottom-up reconstruction which is described in my MSc thesis. The main points are:

  • it scans the whole drive for traces of files
  • it rebuilds the directory tree or any portions of it that can be restored
  • it lets you export the contents of files with the correct names

To run the tool on the image file you made, create an output directory and start RecuperaBit with:

mkdir /path/to/another/drive/recovered_files
cd [full path of recuperabit]
pypy main.py /path/to/backup.dmg -o /path/to/another/drive/recovered_files -s /path/to/another/drive/recovered_files/savefile.save

The -s option stores a useful log of interesting sectors that you can load again in subsequent runs on the same disk image.

After the scanning process, it will start to determine the geometry of any NTFS partition. Run the recoverable command to see the partitions and then, to restore e.g. partition #2:

restore 2 5
restore 2 -1

Where 5 means the Root directory and -1 means the Lost Files directory. You'll probably find a lot of interesting stuff in the Lost Files directory because your drive is damaged.

Check the other answer for a few caveats and limitations.

By the way, since you slightly patched the program for your specific case, it would be nice if you could submit your patch as a pull request.

Related Question