Faster recovery from a disk with bad sectors

Question

Recently I tried to dd from an unhealthy HDD to a file. I used dd if=/dev/sdb of=somefile bs=4096 conv=noerror,sync. My problem was that dd wasted a lot of time when it encountered a bad block. In my use case I would gladly pay with some data loss for a faster result.

Is there any way to make the error handling faster? Maybe a kernel tweak (telling the HDD to make less effort for reading a block)? Or another program?

Answer 1

First, for the software to use: you could try using ddrescue instead of dd.

ddrescue has a switch to do only a limited number of retries. It can also use a logfile, so it records which blocks were bad. If you later feel like doing more retries, you can use the same logfile to run ddrescue again with different options (like more retries) and it will retry only the necessary blocks.

Example usage:

# ddrescue -n /dev/sda /dev/sdb rescue.log
# ddrescue -r1 /dev/sda /dev/sdb rescue.log

From the ddrescue info-page:

   -n, --no-scrape     
          Skip the scraping phase. Avoids spending a lot of time
          trying to rescue the most difficult parts of the file.

   -r, --retry-passes=<n>
          Exit after given number of retry passes. Defaults to 0.
          -1 means infinity. Every bad sector is tried only once 
          in each pass. To retry bad sectors detected on a previous
          run, you must specify a non-zero number of retry passes.

Here are some additional sources to using ddrescue:

• info ddrescue
• http://www.forensicswiki.org/wiki/Ddrescue

---

Edit

In case the HDD itself is taking too long, you can try to enable a feature called TLER (Time Limited Error Recovery) or CCTL (Command Completion Time Limit). Not all HDDs have it, but you can use it to limit the time on the HDD controller itself. This approach can be combined with using ddrecue, of course.

Linux has a tool called smartctl (in the smartmontools package).

To check the current setting ("disabled" means an unlimited time, which you do not want):

# smartctl -l scterc /dev/sda

To set it to a fixed value (5.0 seconds in this example. Setting it to 0 disables TLER):

# smartctl -l scterc,50,50 /dev/sda

Source for TLER: http://en.wikipedia.org/wiki/TLER

Answer 2

For a fast and quick option to rescue the disc you can use a sh script file and run the file with sh. It contains this line, just repeat sudo ddrescue and sleep 3 few more times. The sleep is used to make the drive rest some seconds:

#! /bin/sh -e 
sudo ddrescue -d -r0 -e +0 -T 1s -n /dev/drivepartition file.img log.logfile 
sleep 3

The options used above:

• -r0 : with no retries
• -e +0: exit on first error
• -T 1s: exit with 1 second fail read
• -d : Direct I/O
• -n : no scrape

You can use -R after finish with option -A once, that will reverse and remove all errorsize and start again backwards. Means it will read errors differently.

Answer 3

I had good results from otherwise unreadable disks with this software.

http://www.cgsecurity.org/wiki/TestDisk

This next one is a solid recovery tool as well. It can get files even if your file table is broken or if they were deleted. It's a damn good forensics tool. It dumps things in a really unorganized way, but you can get all of the data moved.

http://www.cgsecurity.org/wiki/PhotoRec

Answer 4

Depends on the size of your hard drive and how many bad blocks it has. It usually takes me 20 min to backup using DD a 1 tera healthy hd. With bad blocks I have just recovered this morning, took me twice the time. I was having problems duplicating (backing up a disk) with about 30 bad blocks. The first thing I have done is backup files using regular Filezilla to backup all good data. I notice that one big file was not copying correctly (Stopping in the middle and restarting the transfer). Luckly I have a previous backup of same file. To duplicate the disk, then I had to find the bad blocks on the disk using this procedure:

1st find out the problem disk identifying the HD info using fdisk -l

2nd if lets say your disk is /dev/sdb then you need to run the command badblocks -v /dev/sdb it will list all you bad blocks on the drive. Luckily there will be a few. If no bad blocks are found, then your drive blocks are OK and need to figure something else out. My block size is 512 so I use that default number to run DD

3rd each block is 512 size, so what I done is to set bs=512

Each time I runned DD regularly as I always do, my data, after the errors, will come out corrupted. So I then use the parameters as explained on the page https://www.gnu.org/software/coreutils/manual/html_node/dd-invocation.html search the "For failing disks" part.

dd if=/dev/sdb of=/dev/sda bs=512 conv=noerror,sync iflag=fullblock 

It took a while. Each bad block encountered sound like a banging on the faulty drive. It does copy block by block, and thru all my bad blocks made the same noise. The amount of times made a noise, was because it found another bad block and tells you about on display error msg. What the ‘conv=noerror,sync’ does, is to pad out bad reads with NULs, while ‘iflag=fullblock’ caters for short reads, but keeps in sync your data up to the end. No corruption at all, it just does not copy the faulty blocks and fills it with empty NULs.

After the copy with DD was done, I just replace that bad file reverting Filezilla from a past backup and everything worked OK. I hope this will be usefull for others trying to backup faulty drives.

NOTE: My bad blocks where pretty much close to each other. About 4 blocks at a time together in groups where detected bad. If your blocks are all over the disk, several files could be affected. Luckly, on my case, a big database 4gb file was only affected.