Hi Mike, There is a retrim flag to clear the bad sectors from the existing log. Though this will clear all the bad sectors from the log which is not desirable. The single errors are usually truly errors and the goal is to trim the giant blob of failed sectors to some thing more manageable anyway. You may have to edit the log manually. It is pretty simple, the documentation on their website describes the format. If I remember correctly the format is position, size, status (numbers are in HEX). Find the manual here <https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html>. Section 6 is the logfile (now known as the map file). You can use ddrescueview to see where the bad blocks are distributed on the drive for a more visual idea of what's going on. If it locked at 1 error then just jumped to finish the rest --max-errors=+X may be useful it will stop trying to read the drive after X error(s). I had a drive a while back where it would stop reading the drive completely after the first error and only power cycle would bring it back. That one took nearly 100 attempts to read all the way but I got everything off of it. You should also try the read in reverse flag (--reverse) if it just gets stuck in the center of the drive. Using the direct io flag (on v1.20 of ddrescue --idirect) can help deal with bad sectors as the kernel doesn't handle them (mostly to avoid buffers). I almost always use it when cloning bad drives - it seems to speeds things up and prevents unnecessary retries in reading the media (in theory - I don't know this for sure) On a side note: I usually clone to file if I can - there is a bit more flexibility with manipulating it though a drive should work well too. (I usually end up doing NTFS recoveries from bad drives over the network with raw images mounted after ddrescue saves all the data) Best of luck with this. On Sun, Sep 13, 2015 at 4:02 PM Mike Miller <mbmiller+l at gmail.com> wrote: > At about 400 GB I picked up 4 errors, then nothing for a long time. I > left the house for a while and came back to this, which seems bad: > > $ sudo ddrescue -v -n --force /dev/sda /dev/sdb ddrlog.txt > GNU ddrescue 1.19 > About to copy 2000 GBytes from /dev/sda to /dev/sdb. > Starting positions: infile = 0 B, outfile = 0 B > Copy block size: 128 sectors Initial skip size: 128 sectors > Sector size: 512 Bytes > > Press Ctrl-C to interrupt > rescued: 951404 MB, errsize: 1048 GB, current rate: 0 B/s > ipos: 2000 GB, errors: 63, average rate: 49658 kB/s > opos: 2000 GB, run time: 5.32 h, successful read: 4.53 m ago > Finished > > It's a 2 TB HDD, so it looks like it did half of it. > > Any opinions on the best next step? > > Mike > > > On Sun, 13 Sep 2015, Mike Miller wrote: > > > Thanks again, Dan. I ended up starting it before getting your message > below, > > but I think I've got it right. /dev/sdb1 was working and I backed up > all of > > it. /dev/sda1 couldn't be mounted, but they previously were cloned. So > I > > unmounted /dev/sdb, installed GNU ddrescue (on a third drive) and did > this: > > > > sudo ddrescue -v -n --force /dev/sda /dev/sdb ddrlog.txt > > > > After that finishes, I will run this to try to get the bad parts: > > > > sudo ddrescue -v -r1 /dev/sda /dev/sdb ddrlog.txt > > > > (I'm not sure if I need --force with the second command, but I was > forced to > > use it with the first command.) > > > > The first command has been running for 45 minutes so far and it reports > zero > > errors and 100 MB/s average throughput. So far, so good. > > > > Mike > > > > > > On Sun, 13 Sep 2015, Dan Armbrust wrote: > > > >> On 09/12/2015 03:21 PM, Mike Miller wrote: > >> Wow, Dan, thanks so much for all the ideas! This is a huge help. > >> Here's what's going on: > >> > >> I already formatted the new drive with ext4 and copied 3 TB of > data > >> onto it, so I don't want to undo all that right away, but there is > another, > >> probably more appealing way to go: > >> > >> /dev/sda and /dev/sdb are identical 2 TB drives that were > previously > >> in a RAID1. It looks like sdb somehow disconnected from the RAID, but > sda > >> kept working for a few months before it > >> failed. I can mount /dev/sdb1 just fine and I copied all the > files > >> off of it onto the new external drive. I had no errors. So maybe > /dev/sdb > >> is in pretty good shape. Now that it's backed > >> up, maybe the best plan is to try to copy /dev/sda to /dev/sdb > using > >> one of the dd tools. > >> > >> So here's a question: /dev/sdb is formatted for ext4. If I want > to > >> use it as the destination drive for the dd copy, do I have to use > parted to > >> remove the partition table first? Or what? > >> > >> Thanks again! > >> > >> Mike > >> > >> > >> You don't have to worry about the partition tables or anything - because > >> rather than copying a partition - such as /dev/sda0 you will just be > >> copying the entire disk - so /dev/sda. > >> > >> When you copy the old (failing) disk onto the other disk (that is either > >> the same size, or larger) you will be copying _everything_ - including > the > >> partition table, and the formatting info of the file > >> system. The contents of the disk you are writing to will be completely > >> overwritten. > >> > >> So then your replacement disk will be (exactly) what the failing disk > was, > >> partition table, labels, filesystem and all. Though, you will likely > have > >> some subtle corruption where blocks that couldn't be > >> read have the wrong bit value. > >> > >> So, if you do manage to recover some things - keep in mind that some of > the > >> files my have subtle corruption. > >> > >> Will you notice if 8 bits are flipped in a 2 GB movie? Probably not... > but > >> you would really just have to test the more important files that you > >> recover to make sure they aren't worse than your several > >> month old backup. > >> > >> Dan > >> > >> > >_______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mailman.mn-linux.org/pipermail/tclug-list/attachments/20150914/011a7650/attachment.html>