12

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?

28
+50

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:


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

  • 2
    Another tool to look at is dc3dd which is a forensics version of dd – fpmurphy Apr 25 '15 at 2:21
  • oh nice, I didn't know that tool! – Slizzered Apr 25 '15 at 2:23
  • 1
    I had no idea about that TLER, but it really saved my day. On my disk these was disabled and each time I ran ddrescue my disk blocked after a couple of seconds. Power-off, power-on and next try. Now I set it to 2 seconds with the command you mention and it it never blocks again, it skips some sectors, but at least goes on without interruptions. – Sven Rieke Mar 17 '18 at 19:25
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

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.

0

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.

  • 1
    If the same answer address multiple questions, there's a good chance the questions are duplicates. If so, it's better to answer one and flag the other as a possible duplicate. That avoids bloat of repetitious answers, and linking the questions makes it easier for readers to find all the answers. – fixer1234 Jul 25 at 22:37
  • Not really, but if you think so, let me know so I will erase my answer. I have looked up everywhere for the right solution, but I found a way to fix a problem with my server. There are several other similar questions, that did not answer my problem. So far I found around a dozen similar o related questions all over. I have just answer a couple to write my experience and how I was able to solve it. Let me know if you would like me to erase my answer and I will be happy to do it. Regards. – Luis H Cabrejo Jul 25 at 23:30

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.