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.
ddrescue
has this option:
-a, --min-read-rate=<bytes>
minimum read rate of good areas in bytes/s
If you specify it on your command line with a decent size like 10M
, with any luck, areas that are still able to read but extremely slow will be skipped first, and continue with other areas the drive is still able to read performantly.
Depending on how much is missing in the end, you can still follow it up with a slow pass afterwards.
It's also possible to run ddrescue
in --reverse
mode or force it to start at a specific offset with --input-position=X
so if ddrescue
doesn't skip into a faster region by itself you can force it to do that manually.
Is this really what recovering a failed hard drive feels entails?
Hard to tell since there are so many different types of failures. It also depends on the type of drive, how it handles errors, and sometimes also how the controller itself reacts to bad drives. Check dmesg
for any noise, see if there are bus resets, those should not happen just because a drive encounters a read error. (If that happens, perhaps increase /sys/block/.../device/timeout
)
If your drive supports SCTERC (unlikely for desktop consumer drives) you might be able to tell the drive to not even attempt internal error correction but return read errors directly.
Best Answer
This would seem to just been how
ddrescue
& USB transfers work under OSX. From this thread titled: Subject: [Bug-ddrescue] ddrescue 10x slow under osx.That same thread also had this response.
References