Rescuing a hdd with bad sectors: dd vs gddrescue

Somewhere on the internets I read that gddrescue is superior to dd at least in terms of being able to distinguish between the amount of disk reads performed on a troubled sector. Is this really the case?

time dd if=/dev/sda skip=900343967 of=a.bin count=4 iflag=direct conv=noerror,sync

dd: reading `/dev/sda': Input/output error
2+0 records in
2+0 records out
1024 bytes (1.0 kB) copied, 18.6057 s, 0.1 kB/s
3+1 records in
4+0 records out
2048 bytes (2.0 kB) copied, 18.6707 s, 0.1 kB/s

real 0m18.672s
user 0m0.000s
sys 0m0.004s

Btw, the direct flag really helps, w/o it I was only able to read 1 sector out of 4 (vs 3/4 with it). However, that noticeably slows the transfer speed down - it is at least about 5 times slower for me: 5MB/s vs 25MB/s without this flag. Anyhow, now for the gddrescue (ddrescue) part..

time ddrescue -b512 -c1 -s4b -dnvD -i900343967b -o0b /dev/sda b.bin

About to copy 2048 Bytes from /dev/sda to b.bin
Starting positions: infile = 460976 MB, outfile = 0 B
Copy block size: 1 hard blocks
Hard block size: 512 bytes
Max_retries: 0
Direct: yes Sparse: no Split: no Truncate: no

Press Ctrl-C to interrupt
rescued: 1536 B, errsize: 512 B, current rate: 53 B/s
ipos: 460976 MB, errors: 1, average rate: 53 B/s
opos: 1536 B, time from last successful read: 0 s
Finished

real 0m18.736s
user 0m0.004s
sys 0m0.000s

As shown above, it has taken the exact same amount of time for execution. As expected - same stats: 3/4. However, while I could pad the troubled sectors with 0x00 for dd (conv=sync), gddrescue seems to be missing this functionality? Instead, it just skips the troubled sector w/o writing anything to its position and continues with the next following sector (if I already have data written over that sector in the output file - it will not be overwritten: sometimes that might not be desirable). I'm not sure how will the -t (truncate) option works for a block-device with gddrescue (i guess, it will completely overwrite it with 0x00), but on a regular file it will, as predicted, truncate the whole file w/o doing it only within the offset dimensions (i.e. -o1). So, that is somewhat similiar to dd sync, but far from being the same as it will only mimic identicle functionality IF you are ready to overwrite the whole output device/file.

Although, thanks to the presence of verbose option and the ability to log bad sectors/blocks - gddrescue seems like a better choise. It is important to note, that both of the apps were launched with (pretty much) identical params.

The output of

diff ?.bin

is empty (exit 0), meaning the files are exactly the same.

Now this is the part I DO NOT understand:

dd is slow even on the error-free stuff since it's doing tiny reads and writes. It spends a lot of time chewing through the erroneous parts of the drive, rather than reading as much error-free stuff as it can, THEN going back to do the hard stuff.

What is that all about? Especially the part "it spends a lot of time chewing through the erroneous parts of the drive, rather than reading as much error-free stuff as it can, THEN going back to do the hard stuff"? It took the same amount of time as shown above (even though i have inspected a very tiny portion of data, but should that matter?).

gddrescue offers the -r switch, which should control the amount of re-reads on a "bad sector", however, dd seems to be running with the -r0 all along (as it took the same time). So, is this option merely for "post-processing"? What I am getting at, is that originally both dd and gddrescue seem to be running with -r0 and dd does not seem to be chewing through the erroneous parts any more than gddrescue (they both seem to halt on a bad block for 15-18 seconds give or take, so what's the deal, how is gddrescue faster???)

Also, what is the -D option (use synchronous writes for output file) for? I have not noticed any difference from some of the conducted testing.

Can anyone comment on the whole thing? Thanks.

Solution 1:

I'm not sure how the quoted author came to his conclusion. I'm not debating if he is correct, or not, I just don't have that experience.

On the other hand, in regards to this statement...

gddrescue is superior to dd at least in terms of being able to distinguish between the amount of disk reads performed on a troubled sector.

The real "at least" reason to use gddrescue, is because gddrescue does not truncate output on repeated read/write attempts. gddrescue also is fully automatic, in regards to certain read errors that would stop dd.

So the quoted author may be correct, he may not... but the whole statement misses the point of gddrescue.

UPDATE: Detailed differences between dd and gddrescue.

dd conv=noerror, will keep going after an error, but it will just skip the bad block. even adding the sync option will just put zeros instead of skipping. If you use dd to do another read using the same output, you will just overwrite/lose anything you recovered previously.

gddrescue, will also keep going after error. It can recover a partial yield from a bad block, and will go back and attempt the block sector by sector. gddrescue will keep a detailed error log, with good block, bad blocks, and the sector by sector from any bad blocks. If you attempt to perform the read again, gddrescue will cut off (truncate) and add in any additionally recovered data.

Do keep in mind, even with both tools if a whole block in 100% unreadable. You will still get no data from it. gddrescue can potentially get more data, if some sectors in the block are remain readable.

Solution 2:

Depending on when your hdd was maufactured as well as manufacturer, and what version of firmware it runs, with modern hdds, when bad sectors are detected, they are removed from use by the firmware and the drive knows to skip the bad sectors. So, the notion of "rescuing" a hdd from bad sectors may be moot in that regard. The question of whether the now bad sectors once had valid data seems to be the case solution you are seeking - no pun intended!

There is some software at grc.com called spinrite 6 which claims to be able to fix hdds with bad sectors. It is paid software, and I have never tried it. It is worth reading about, especially if one is attempting to "resurrect" a hdd and it actually works as described. The FAQ at grc.com regarding spinrite 6 indicates that there is a 30 day money back guarantee (and there is no trial or free version). Note: I am not affiliated with grc.com, nor am I recommending it for your situation. I just know it exists and might work as advertised, just don't take my word for it - caveat emptor.

With regard to assessing whether gddrescue "is superior" to dd at least in terms of being able to distinguish between the amount of disk reads performed on a troubled sector, any number of reads on a bad sector (since it is marked as a non-functional sector in a list of bad sectors kept in a firmware list) would not seem to me to be useful in a qualitative use of either gddrescue or dd.

You may find it useful to read the web page, dd (Unix) at: https://secure.wikimedia.org/wikipedia/en/wiki/Gddrescue#Recovery-oriented_variants_of_dd

You might also find it useful to have a look at: How to Create an Image of a Crashed Hard Drive using the UBCD, dd-rescue and P2 eXplorer at: http://www.myfixlog.com/fix.php?fid=21