ddrescue seems to get stuck

garydale · 05-17-2018, 10:46 PM

I'm trying to rescue a hard drive that seems flaky. Ddrescue goes along fine for while then seems to stop making progress. Moreover, it's not uninterruptible by ^C despite the message saying it can be. I can however interrupt it by pulling the USB cable. When I restart it, it goes along for a while then stops again. After 24 hours and multiple restarts, my image file is only 28G while the original device is 1T.

Below is output from ddrescue after it got stuck for many hours. I was out and when I came back, the screen hadn't changed. However after I pull the USB cable, some numbers do change. When

The drive seems to be being accessed continually even when ddrescue isn't reporting progress. Does anyone have any ideas on what is going on?

Code:

root@transponder:/home/garydale# ddrescue /dev/sdl ./.data/rescue.img ./.data/mapfile
GNU ddrescue 1.22
Press Ctrl-C to interrupt
Initial status (read from mapfile)
rescued: 2326 MB, tried: 196608 B, bad-sector: 0 B, bad areas: 0

     ipos:   29593 MB, non-trimmed:    5753 MB,  current rate:       0 B/s
     opos:   29593 MB, non-scraped:        0 B,  average rate:   1860 kB/s
non-tried:  970605 MB,  bad-sector:        0 B,    error rate:   3876 MB/s
  rescued:   23845 MB,   bad areas:        0,        run time:  3h 12m 45s
pct rescued:    2.38%, read errors:    87889,  remaining time:         n/a
                              time since last successful read:          1s
Copying non-tried blocks... Pass 5 (forwards) 
ddrescue: Input file disappeared: No such file or directory
root@transponder:/home/garydale# ddrescue /dev/sdl ./rescue.img ./mapfile
GNU ddrescue 1.22
Press Ctrl-C to interrupt
Initial status (read from mapfile)
rescued: 23845 MB, tried: 5753 MB, bad-sector: 0 B, bad areas: 0

     ipos:   29797 MB, non-trimmed:    5753 MB,  current rate:    131 kB/s
     opos:   29797 MB, non-scraped:        0 B,  average rate:   4865 kB/s
     ipos:   29819 MB, non-trimmed:    5753 MB,  current rate:       0 B/s
     opos:   29819 MB, non-scraped:        0 B,  average rate:    6737 B/s
non-tried:  970379 MB,  bad-sector:        0 B,    error rate:       0 B/s
  rescued:   24071 MB,   bad areas:        0,        run time:  9h 19m 26s
pct rescued:    2.40%, read errors:        1,  remaining time:  2d  8h  8m
                              time since last successful read:          0s
Copying non-tried blocks... Pass 5 (forwards)

Shadow_7 · 05-18-2018, 12:16 AM

I had an issue on an older atom laptop (CMOOV issue???). Using dd under ubuntu basically crashed on me (July-ish 2015). Using dd under debian worked just fine. Perhaps a place to start.

descendant_command · 05-18-2018, 01:33 AM

Sounds like some badblocks or such giving extended iowaits ...
Just leave it running - that’s what ddrescue was designed to cope with.
Starting from the other end of the drive might help too, or skip the problematic sectors and come back to them later.

garydale · 05-18-2018, 03:19 AM

Quote:

Originally Posted by Shadow_7

I had an issue on an older atom laptop (CMOOV issue???). Using dd under ubuntu basically crashed on me (July-ish 2015). Using dd under debian worked just fine. Perhaps a place to start.

I'm actually running under Debian (Buster), not Ubuntu, on an AMD64 system. And dd is not the same as ddrescue.

garydale · 05-18-2018, 03:28 AM

Quote:

Originally Posted by descendant_command

Sounds like some badblocks or such giving extended iowaits ...
Just leave it running - that’s what ddrescue was designed to cope with.
Starting from the other end of the drive might help too, or skip the problematic sectors and come back to them later.

I recently used ddrescue to copy similar sized disks with lots of bad blocks and it worked OK, copying 1T in less than a day. This seems to be something different. Ddrescue isn't even updating the run time.

Does ddrescue have any issues with USB drives (as opposed to SATA) that you know of? If the drive is failing, the last thing I need is for a program to pound it trying to read.

I just tried the reverse run and this happened:

Code:

root@transponder:/home/garydale# ddrescue -R /dev/sdl ./.data/rescue.img ./.data/mapfile
GNU ddrescue 1.22
Press Ctrl-C to interrupt
Initial status (read from mapfile)
rescued: 24088 MB, tried: 5754 MB, bad-sector: 0 B, bad areas: 0

     ipos:  999458 MB, non-trimmed:    6111 MB,  current rate:       0 B/s
     opos:  999458 MB, non-scraped:        0 B,  average rate:   1186 kB/s
non-tried:  969614 MB,  bad-sector:        0 B,    error rate:    357 MB/s
  rescued:   24478 MB,   bad areas:        0,        run time:      5m 27s
pct rescued:    2.44%, read errors:     5456,  remaining time: 12d 21h 24m
                              time since last successful read:          0s
Copying non-tried blocks... Pass 5 (backwards)
ddrescue: Input file disappeared: No such file or directory

This is the same thing I see when I unplug the USB cable to kill the job (when it wouldn't respond to ^C) but this failed on its own. /dev/sdl still shows up on an ls -l /dev/sd* and restarting the job worked.

syg00 · 05-18-2018, 03:34 AM

If the device node is disappearing, you probably have hardware issues - maybe the port isn't up to the job. Do you have external power ?.

descendant_command · 05-18-2018, 03:36 AM

Looks like it might be more serious trouble with that drive then.
If the drive won’t supply any data, not much ddrescue can do.

garydale · 05-18-2018, 10:28 AM

Quote:

Originally Posted by syg00

If the device node is disappearing, you probably have hardware issues - maybe the port isn't up to the job. Do you have external power ?.

Of course there are hardware issues. That's why I'm using ddrescue.

The external USB case is powered.

I'm working with the theory that the drive electronics are flaky. The computer I took the drive from would take 30 minutes or longer to boot. It wasn't always successful and when it did, it would be slow to respond.

To make matters worse, I couldn't get into the BIOS which prevented me from booting from a CD or USB stick. I put the drive in a USB case to try to recover the data on it, which led to the current problem.

I first tried to run smartctl -H on it, but that never returned a result so I figured better try to make an image of the drive ASAP.

------------

Wonderful - after a reboot, Linux rearranged the drive letters so the drive I was trying to recover switched with a working drive and overwrote the data I'd recovered. Back to square 1.