Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I had a 500GB drive HDD crash about 5 days ago. I used ddrescue on the important partition a few days ago, and it's been on "Trimming failed blocks" for almost 2 days now.

Original command:

ddrescue -n /dev/rdisk1s2 /Volumes/OSXBackup/rdisk1s2.img /Volumes/OSXBackup/rdisk1s2.log

Current output:

Initial status (read from logfile)
rescued:   248992 MB,  errsize:   1007 MB,  errors:   15867
Current status
rescued:   249021 MB,  errsize:    978 MB,  current rate:    17408 B/s
   ipos:    44405 MB,   errors:   15866,    average rate:     2784 B/s
   opos:    44405 MB,     time from last successful read:       0 s
Trimming failed blocks...

The original command used the ddrescue -n parameter, and I have restarted the process a few times as needed (and it seemed to pick up right where it left off each time).

Is there any way to speed up this process?

Edit: Six hours later, this is the current status:

rescued:   249079 MB,  errsize:    920 MB,  current rate:      409 B/s
   ipos:    39908 MB,   errors:   15851,    average rate:     2698 B/s
   opos:    39908 MB,     time from last successful read:       0 s
Trimming failed blocks...

It appears that while "errors" is counting down excruciatingly slowly, ipos/opos is counting down how much data it has to churn through, and it seems to be working at a rate of 750MB/hour. At this rate, it will complete in ~53 hours. Yikes.

Edit #2: Two days later, still running. However, there is hope. It has moved passed the "Trimming failed blocks" portion, and on to the next phase "Splitting failed blocks". If anything, what should be taken away from viewing this question is that this definitely takes a long time when a good amount of data/errors are involved. My only hope is that I can successfully recover some important data when all is said and done.

rescued:   249311 MB,  errsize:    688 MB,  current rate:        0 B/s
ipos:    26727 MB,   errors:   15905,    average rate:     1331 B/s
opos:    26727 MB,     time from last successful read:      20 s
Splitting failed blocks...
share|improve this question
Its by design, most likely. It does multiple passes to extract as much data out as possible –  Journeyman Geek Apr 18 '12 at 5:36
Crash a smaller hard drive next time ;-) –  Joey Apr 18 '12 at 6:04

4 Answers 4

If your aim is to obtain the bulk of the data intact, then you could speed up its extraction. But if you really want to rescue as much data as possible, then letting ddrecue nibble at each and every is the route to take.

share|improve this answer

I observed that using the -n (no-split) option together with "-r 1" (retry once) and setting "-c" (cluster size) to a smaller value can help.

My impression is that the splitting step is very slow as ddrescue splits and splits again the damaged areas. This takes a lot of time because ddrescue tries to restore very small portions of data. So, I prefer to use "-n" (no-split) together with "-c 64", "-c 32", "-c 16", a.s.o.

Probably the -n (no-split) should always be used for one first pass in forward and reverse directions. It seems that the more the data were splitted, the slower the cloning, although I'm not sure about this. I assume the larger the non-treated areas, the best when running ddrescue again, because more contiguous sectors are to clone.

As I'm using a logfile, I don't hesitate to cancel the command with "Ctrl+C" when the data read speed becomes two low.

I also use the "-R" (Reverse) mode and after a first pass it often gives me higher speeds reading backwards than forward.

It's not clear to me how already retried sectors (-r N) are handled when running the ddrescue command again, especially when alternating forward (default) and reverse (-R) cloning commands. I'm not sure if the number of times they were tried is stored in the logfile and probably the work is done again useless.

Probably the -i (input position) flag can help speed up things too.

share|improve this answer

It can be very hard to see the progress of ddrescue, but there is another command included called ddrescuelog.

A simple command "ddrescuelog -t YourLog.txt" will output these nice infos:

current pos:     2016 GB,  current status: trimming
domain size:     3000 GB,  in    1 area(s)
rescued:     2998 GB,  in 12802 area(s)  ( 99.91%)
non-tried:         0 B,  in    0 area(s)  (  0%)

errsize:     2452 MB,  errors:   12801  (  0.08%)
non-trimmed:   178896 kB,  in 3395 area(s)  (  0.00%)
non-split:     2262 MB,  in 9803 area(s)  (  0.07%)
bad-sector:    10451 kB,  in 19613 area(s)  (  0.00%)

You can even use it while ddrescue is running...

share|improve this answer

I have found that playing with the -K parameter you can speed things up. From what I've seen if ddrescue finds an error when running with the -n option tries to jump a fixed amount of sectors. If it still can't read it jumps double the size. If you have large damaged areas you can indicate a big K value (for example 100M) and so the jumping on an error will be larger the first time and it will be easier to avoid problematic areas quickly in the first past.

By the way, there is a wonderful graphical application to analyze the log.


share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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