Is this ddrescue command doing anything?

Question

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

Solution 1

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:

$ sudo ddrescue -d /dev/sdb /home/dave/RECOVERY/usb500.image \
     /home/dave/recovery_usb500.logfile --force -R

• -d which tells ddrescue to use direct disk access,
• --force which tells ddrescue to forcefully use and read/write to your logfile in case if it complains that it can't use it for read/write purposes
• -R (yes, with CAPITAL R) which tells 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 that ddrescue 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 again ddrescue with CTRL+C, power cycle the hard drive, and restart ddrescue, 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.

Solution 2

You should be able to stop ddrescue as it uses the log file to be able to restart its operation (close) to where it left of. I would check however if the logfile has been recently updated by looking at the timestamp or doing tail -f /home/dave/recovery_usb500.logfile.

That your image file is still that small might have to do with no blocks successfully having been retrieved from the drive yet. That would however be bad result after all this time running. Assuming there are just a few bad blocks on the device, and that they are not at the beginning, your first entries status would be +. IIRC ddrescue starts reading until it finds an error and then starts splitting the rest of the disc. Your disc seems to fail right from the start.

Unless there are (multiple) + entries in the log and your file size would still be 0 I don't think ddrescue is wrong. No +s mean that nothing from your drive was recoverable. That might mean fried electronics or a a bad head, as in case of just a few sectors being faulty you would have had results much quicker.

As for doing something else. I assume you already tried reading a few blocks with normal dd. Have you looked at the syslog based on that and googled any messages you found there?

---

Searching for "Result: hostbyte=invalid driverbyte=DRIVER_SENSE" results in a few interesting reads (partly German) with a few more suggestions:

• Try connecting via USB 1.1 instead of 2.0
• The drive might get to hot, therefore wrap it in plastic and put it in the fridge for 10 minutes, this gives some readability time before the drive heats up again.
• switch of SMART in the BIOS (and connect with SATA).
• Make sure the USB drive has enough power (extra power supply)
• If reading over USB fails after some time, use a remotely controlled USB Hub where you programmatically toggle the power from the USB HUB to the drive of for a few seconds.

Apart from cooling an unreadable disk (with cooling spray) I have not tried any of these myself.

Comments

[ADAM]

Thanks for responding. I haven't tried a "normal" dd, as I don't know what that is. My gut feel is that most of the drive and data is intact, but there is some fault in some critical area of the disk where indexing or listing files takes place.

[Anthon]

You could consider ddrescue is a derivative of dd that does not stop when an error is encountered. Did you check for + signs?

[ADAM]

In the log file, there are no + signs. There are only - and \ signs.

[Anthon]

That means nothing has been recovered yet, and I think it unlikely that ddrescue will start after all this time. If you want we can chat (link top of this page) about this

[ADAM]

I've added the contents of /var/log/syslog to the question.

[Anthon]

@DaveMG I added a few more options I found googling for stuff from syslog.

[baroquedub]

Actually I thought that was one of the most constructive and detailed posts I've seen on the subject. I hope you don't mind, I've just added a similar question unix.stackexchange.com/q/219365/125662 that mentions your really helpful contribution

[Mpunkt Moeniac]

From the GNU ddrescue manual: "--force Force overwrite of outfile. Needed when outfile is not a regular file, but a device or partition. This option is just a safeguard to prevent the inadvertent destruction of partitions, and is ignored for regular files." This ist not about the mapfile/logfile.

[endolith]

Please fix the description of --force option, it is not correct