4

I'm using ddrescue to image a drive, and it's slowed down to about .1 % as fast as it started, at this rate I'm not sure if it will even finish, at any rate, I'm not sure I can tie up this machine that long to do it. Hoping someone can help, or recommend some other way to image the drive?

The setup: - macbook pro running 10.8 - ddrescue installed from macports - source drive is in the freezer, with cables running out to the laptop using a SATA to usb adapter - target drive in an identical model of a 640gig maxtor in a sata to usb enclosure - command used was: - log file is being written to /root/rescue.log ( on whatever file system / is on a macbook) - terminal output from the command and my attempt to resume below, you can see it was averaging 7000kbs and is now averaging about 5000 bps!

Any tips much appreciated! Iain

Iains-MacBook-Pro:~ root# ddrescue -f -g -v -n /dev/disk1 /dev/disk2 /root/rescue.log
ddrescue: warning: Options -aCdDeEIMnOprRStTx are ignored in generate mode.


GNU ddrescue 1.16
About to generate an approximate logfile for /dev/disk1 and /dev/disk2
    Starting positions: infile = 0 B,  outfile = 0 B
    Copy block size: 128 sectors
Sector size: 512 Bytes

Press Ctrl-C to interrupt
rescued:     2543 MB,  generated:    2731 MB,  current rate:    8847 kB/s
   opos:     2731 MB,                          average rate:    9134 kB/s
Generating logfile...
ddrescue: Error opening logfile '/root/rescue.log' for writing: No such file or directory
Fix the problem and press ENTER to retry, or Q+ENTER to abort. 


rescued:   474160 MB,  generated:  499761 MB,  current rate:     5461 B/s
rescued:   474160 MB,  generated:  499761 MB,  current rate:     3449 B/s
   opos:   499761 MB,                          average rate:    7440 kB/s
Generating logfile...
Interrupted by user
Iains-MacBook-Pro:~ root# 
Iains-MacBook-Pro:~ root# ddrescue -f -g -v -n /dev/disk1 /dev/disk2 /root/rescue.log
ddrescue: warning: Options -aCdDeEIMnOprRStTx are ignored in generate mode.


GNU ddrescue 1.16
About to generate an approximate logfile for /dev/disk1 and /dev/disk2
    Starting positions: infile = 0 B,  outfile = 0 B
    Copy block size: 128 sectors
Sector size: 512 Bytes

Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:   474160 MB,  generated:  499761 MB
Current status
rescued:   474164 MB,  generated:  499765 MB,  current rate:     5041 B/s
   opos:   499765 MB,                          average rate:     8793 B/s
Generating logfile...
Improve this question
3

This is expected behaviour of ddrescue. It slows down to read smaller chunks in damaged areas of the disk. Given that your drive is in the freezer, I assume it's in trouble and you're trying to salvage information. Ddrescue is the tool I'd use in that situation.

From the manual

The algorithm of ddrescue is as follows (the user may interrupt the process at any point, but be aware that a bad drive can block ddrescue for a long time until the kernel gives up):

1) Optionally read a logfile describing the status of a multi-part or previously interrupted rescue. If no logfile is specified or is empty or does not exist, mark all the rescue domain as non-tried.

2) Read the non-tried parts of the input file, marking the failed blocks as non-trimmed and skipping beyond them, until all the rescue domain is tried. Only non-tried areas are read in large blocks. Trimming, splitting and retrying are done sector by sector. Each sector is tried at most two times; the first in this step as part of a large block read, the second in one of the steps below as a single sector read.

3) Read backwards one sector at a time the non-trimmed blocks, until a bad sector is found. For each non-trimmed block, mark the bad sector found as bad-sector and mark the rest of that block as non-split.

4) Read forwards one sector at a time the non-split blocks, marking the bad sectors found as bad-sector. After a number of consecutive bad sectors is found in a block large enough, the block is split by half and the reading continues on the second half. This recursively splits the largest failed blocks without producing a logfile too large.

5) Optionally try to read again the bad sectors until the specified number of retries is reached.

6) Optionally write a logfile for later use.

Improve this answer
  • Hey, I know it's over a year and a half later but with a logfile I can stop any time and restart later? Also mine has slowed to a consistent 30mb/s read with the error count stagnant (at 41) it's a 4tb drive and it's just under 500gb in, it was going 170mb/s. Will it pick back up? – Alec Teal Dec 30 '14 at 11:53
  • @AlecTeal, no that would make no difference, because it would resume with the focus still on the unrecovered portions of the disk. when ddrescue is attempting to read data off damaged parts of the disk surface, it has to slow down, and reread the data many times in order to get a clean read, so the problem, is not so much a problem but a feature. – Frank Thomas Dec 30 '14 at 20:51
1

As per the manual info in @ForeverWintr response, it may be an idea to stop the connection and attempt to read the disk backwards, which may allow you to pick up more information quickly if your disk is dying. You can also tell ddrescue to skip larger blocks initially, but in the end, yes, DDRescue can take ages (forever ?) to try and recover absolutely as much as it can. You may reach the point where you just have to take what you can get and write off the bits it can't read. Often though, the longer you leave it the more it will recover. I had a 320 gig drive which took days to pull virtually all the data off - the process was very slow as the disk was dying - I suspect it got all but about 100k off the disk in the end.

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.