4

I'm trying to recover a partition on a bad drive with ddrescue. I run:

$ sudo ddrescue -r -1 -v /dev/sdd3 OUT.img dd_rescue_logfile

and it seems to do great for a while, but after about an hour, the "current rate" drops to zero because the drive disappeared from /dev. To bring the drive back, the only thing I can think of is to reboot the system and run the ddrescue command to resume from where I left off. This makes it very difficult to run the program, as I can't just leave it and forget it for a few days - I have to constantly monitor it to make sure the disk didn't disappear. I have seen this behavior on both Arch linux, and Fedora 22.

I assume that at some point, the kernel has trouble accessing the drive and removes it from /dev. Is there any way to avoid this? To tell the kernel to keep the device there even if it looks like it's broken or non-existent?

2

You might be able to re-detect it without reboot, by unloading / re-loading the correct module (or just un-binding and re-binding the driver).

For example:

[  978.527221] sd 11:0:0:1: [sdk] Attached SCSI removable disk
#~> echo 11:0:0:1 > /sys/bus/scsi/drivers/sd/unbind
#~> echo 11:0:0:1 > /sys/bus/scsi/drivers/sd/bind
[ 5572.027119] sd 11:0:0:1: [sdk] Attached SCSI removable disk

Or if that does not work and you have no other devices hooked to the same controller, you could unbind and bind the entire controller for example via /sys/bus/pci/drivers/ahci/ if it's AHCI.

I don't have any defective HDD to test if it would actually work, but I used this method before to force re-detection of MicroSD/MMC cards in slots that were not hot-pluggable by default.

As for ddrescue dropping speed to zero, you might want to see if it supports the -a, --min-read-rate=<bytes> option so it would hopefully? consider slow regions as defective and skip them. Worst case you'll have to monitor the disk from the outside and forcibly restart ddrescue.

| improve this answer | |
  • dmesg was showing me a ton of errors on 'sd 4:0:0:0', so I'm assuming that's the drive I'm looking for. I tried unbinding and binding it like you suggested, but it's still not visible. How do I check if it's the only drive on the controller, and which controllers I have available? – Tal Jul 25 '15 at 17:41
  • lspci, and if it's AHCI, ls /sys/bus/pci/drivers/ahci/ would have links to individual controllers and they contain links to ataX... – frostschutz Jul 25 '15 at 19:03
0

I too was running into this situation where the source /dev/sdx device would disappear shortly after ddrescue's startup and knew that unplugging and re-plugging in the USB "toaster" I was using to attach the SATA drive to the system would cause it to be re-found. Restarting ddrescue would allow it to run for a few minutes, before crashing shortly thereafter. Using lsblk, it was easy to see if the drive was connected, or not. Anyway, I ran ddrescue several times on 1 Ubuntu system, then on a more up to date 19.04 Ubuntu, with a slightly older ddrescue (1.23). Still experiencing the problem, even after trying the bind/unbind remedies mentioned above and elsewhere, I thought I'd simply try to run ddrescue on a CentOS 7 system (CentOS Linux release 7.7.1908 (Core)), using ddrescue version 1.24 with kernel 3.10.0-1062.12.1.el7.x86_64 #1 SMP Tue Feb 4 23:02:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux and Success! I've had numerous errors on the drive while running (as per /var/log/messages), but it's been running over 10 hours at this point without a single instance of the harddrive disappearing. What made me try a CentOS system again was I ran into a similar recovery situation a couple of years ago and found that the CentOS 6 system I was using back then didn't lose the drive. Hope this helps.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.