In the course of trying to recover data from a failing hard drive, I am running the command ddrescue
.
The command has been running for 9 days, and I thought from the sound of disk activity that maybe it was doing something. The command line output has looked more or less static all this time:
$ sudo ddrescue -r3 /dev/sdb /home/dave/RECOVERY/usb500.image /home/dave/recovery_usb500.logfile
Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued: 0 B, errsize: 0 B, errors: 0
Current status
rescued: 0 B, errsize: 500 GB, current rate: 0 B/s
ipos: 2539 MB, errors: 1, average rate: 0 B/s
opos: 2539 MB, time from last successful read: 9.7 d
Splitting failed blocks...
The one part that has been changing is where it says ipos
and opos
. It took 9 days to get up to around 500000 MB
, which is the size of the failing disk drive. When it got there, though, it then dropped back down to 0
and started rising again. As I write this, it's at about 2580 MB
and counting.
The image file being created is 0 bytes in length.
The log file is about 3MB in size and looks like this:
# Rescue Logfile. Created by GNU ddrescue version 1.14
# Command line: ddrescue -r3 /dev/sdb /home/dave/RECOVERY/usb500.image /home/dave/recovery_usb500.logfile
# current_pos current_status
0x975C3000 /
# pos size status
0x00000000 0x00862000 -
0x00862000 0x00014800 /
0x00876800 0x00800400 -
~~~~~~edited for brevity ~~~~~~~~
0x74702CCE00 0x00320000 -
0x74705ECE00 0x00025800 /
0x7470612600 0x005F3A00 -
I'm starting to be concerned that this is just a waste of time and no data is being recovered at all.
Is there any indication from this output that anything useful is happening?
Is there any reason to let the ddrescue
command continue as is, or should I stop it and do something else?
This is the most recent contents of /var/log/syslog
Jun 10 07:29:17 homebase-i3 kernel: [568470.316436] sd 5:0:0:0: [sdb] Sense Key : Medium Error [current]
Jun 10 07:29:17 homebase-i3 kernel: [568470.316443] sd 5:0:0:0: [sdb] Add. Sense: Unrecovered read error
Jun 10 07:29:17 homebase-i3 kernel: [568470.316450] sd 5:0:0:0: [sdb] CDB: Read(10): 28 00 11 ff 02 98 00 00 08 00
Jun 10 07:29:17 homebase-i3 kernel: [568470.316465] end_request: critical target error, dev sdb, sector 301925016
Jun 10 07:29:17 homebase-i3 kernel: [568470.346640] sd 5:0:0:0: [sdb] Unhandled sense code
Jun 10 07:29:17 homebase-i3 kernel: [568470.346646] sd 5:0:0:0: [sdb] Result: hostbyte=invalid driverbyte=DRIVER_SENSE
Jun 10 07:29:17 homebase-i3 kernel: [568470.346651] sd 5:0:0:0: [sdb] Sense Key : Medium Error [current]
Jun 10 07:29:17 homebase-i3 kernel: [568470.346656] sd 5:0:0:0: [sdb] Add. Sense: Unrecovered read error
Jun 10 07:29:17 homebase-i3 kernel: [568470.346662] sd 5:0:0:0: [sdb] CDB: Read(10): 28 00 11 ff 02 98 00 00 08 00
Best Answer
I don't know if you are still trying to extract data off that hard drive or if you were successful already, but in case if you were not successful and would like to give it a try to see if you can recover, perhaps, lost Bitcoins or whatever, I have made a few modifications to your
ddrescue
command line parameters, I have added the following:ddrescue
to perform the recovery operations in reverse instead of reading off the failed hard drive in forward mode. Sometimes reading in reverse helps when the damage is substantial as this bypasses the hard drive's cache in case if there are problems there.Currently I am using these commands (except I am not using the
3
command as I don't want [YET]ddrescue
to retry bad sectors, I will leave that for last, after my first sweep is done, and I am having a great success rescuing data off my 1TB Seagate failed hard drive where I ASSUME might be holding a few bitcoins I may have been mining back in 2009 to 2010, probably I found 1 to 3 blocks of 50 BTC each, I hope it's on this hard drive, well, it will take me a total of over 15 days to complete the operation at a read rate of 634 kbps average.Also, I would like to add that you may and most likely, based on your previous track record of over 9 DAYS of "last read activity" that you will encounter a situation where the hard drive will just refuse to read any further, in that situation, just press the CTRL + C to cancel since you are using a log file, remove the SATA cable off the failed hard drive, but not the USB controller off the USB port (yes, use a USB SATA controller instead of connecting it to a motherboard so it would not lock out your whole computer forcing you a hard reboot, and then plug in the SATA power back on to restart the hard drive, give it like 10 seconds and then press the up or down arrow to reload your previous terminal command and restart the
ddrescue
operation, thanks to your previous log it shall continue where it last left off and there will be reading being done and the "last successful read" shall always stay at "0s" (zero seconds) where it should, indicating thatddrescue
is being successful in reading from the hard drive, and if you ever notice that the "last read from" starts counting seconds, just terminate once againddrescue
with CTRL+C, power cycle the hard drive, and restartddrescue
, there is no point in waiting to see if the "last read from" restarts back to 0s on its own, based on my experience it's never going to happen, you will be waiting for eternity. I had to power cycle my bad 1 TB hard drive about 20 times in total, it's been like 7 days and I am very close to reaching the 500GB recovered mark, half way to go still, hope I won't encounter any major failures as I near 100% as it has been going flawlessly for the past 3 days, again at over 634 kbps.Also, don't get greedy at trying to get a faster data throughput read rate, as my attempt at trying many parameters and different block sizes almost left me with a completely dead hard rive that will stop working in over 1 second after power cycling it (that was 5 days ago) but thankfully it just started once again showing sign of life, initially reading at 2,000 bs (yes BYTES per second) a little less than 2kbps, I was very disappointed, but after canceling
ddrescue
with CTRL + C and just restarting it once again (in reverse with the -R) parameter added, then speed went back to 630, before I was reading forward at 930 kbps, at least I am content that I am doing 630 kbps in reverse and not having to put off with 2kbps, so if you get a success at any read speed, like in the 500 kbps range stick with it and don't try anything to push speeds any higher, it may be your last successful attempt at gaining any read speed.Alternatively, if
ddrescue
is of no good for you because you can't get anything read regardless of what parameters you try, you may want to consider replacing the logic board off the hard drive, as 90% of the time it's the logic board that goes bad, but first, take off the logic board and clean all the contacts that makes contacts with the hard drive's pins, some times these contacts gets a blackish gooey mixture in it, severing contact which could be the source of your failure. But be aware that if you have to replace your hard drive's logic board, you will have to get one of the same brand, serial number (close to), model number, revision number because it has to be as close to as the original for the donor board to work.