bug-ddrescue
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-ddrescue] Interpreting logfile of restore to get list of corrup


From: DePriest, Jason R.
Subject: Re: [Bug-ddrescue] Interpreting logfile of restore to get list of corrupted files
Date: Wed, 27 Sep 2006 18:04:23 -0500

Not to hawk a non-free, non-opensource product, but I have had luck
repairing failed disks with SpinRite 6.0.

http://www.grc.com/sr/spinrite.htm

It fixed a disk drive formatted as NTFS (but the program works at the
hardware level and doesn't care what the filesystem is).

The disk was unbootable and gave an error from the MBR of "Operating
System Not Installed"

It took over 48 hours to fix it, and it still wouldn't boot, but I
could mount it and get my files back.

-Jason

On 9/27/06, Ariel <> wrote:

On Wed, 27 Sep 2006, Chris Witham wrote:

> On 9/26/06, Ariel <> wrote:

>> http://smartmontools.sourceforge.net/BadBlockHowTo.txt

> Thank you.  This is exactly the information I wanted.

> The problem is that my failed partition is ReiserFS.  The icheck and
> ncheck commands are part of debugfs, which is ext2/ext3-specific, and
> all I can find online is other people complaining that ReiserFS
> doesn't have an equivalent command.  There doesn't appear to be any
> way to get ReiserFS to tell what files are on what sectors.

You might want to email a list dedicated to ReiserFS.

> However, ddrsummarize.pl (thank you Dave!) shows that the 1688 bad
> sectors mentioned in the logfile actually translates to less than 1MB
> of data lost.

1688 * 512 = 800KB.

> This makes me happy (I can deal with 800kB of lost
> data, out of 111GB) and annoyed (all this trouble over only 800kB?).

That's actually normal. And it's the best way to fail a hard disk - just a
few sectors go bad, and you find out right away, before more fail.

Be glad it's this type of failure, and not a total loss of the hard disk.
BTW what model hard disk is this? Failures are inevitable, when a disk
fails slowly like this it's a plus.

> I will just restore the drive and find out through trial and error
> what does and doesn't work.

That won't work. Any file that was not restored will have 0's, for the
data. It's not something that is easy to detect, it will not give a disk
error, it just will have a blank area. If it's a program it might not even
crash till it happens to execute that code, depending on your usage, it
might never. A document will simply have a blank area, etc.

If the 0's are for a directory entry, that should be pretty obvious when
you run fsck, but for files you won't be able to tell without checking
each one.

You should copy your data, and reinstall the OS. If that's too much work,
then at least refresh each file - meaning get the original, and copy it
over the existing. (In debian it's easy, just apt-get --reinstall and a
list of packages.)

One other options: if you are 100% done with recovering your data, and you
don't need anything else on the old hard disk, then try to mount it, and
then copy every single file to /dev/null - then watch where the errors
are. But be careful - the kernel could crash if the fs is corrupted badly.
Also if a directory entry is bad, you will not be able to check the files
under it.

        -Ariel





reply via email to

[Prev in Thread] Current Thread [Next in Thread]