Re: [Bug-ddrescue] ddrescue 1.3 - questions from a newbie

[Ariel]

On Mon, 8 Jan 2007, Matt Boge wrote:

> ... I was hoping that I could clone the disk, have Windows repair the 
> bad file and not have to reinstall all my apps.

It's not going to be just one bad file, and you will have to reinstall 
everything. But, maybe you can recover your _data_.

When disks fail like this, often what fails (at least by me) is the write 
head, and everything that got written to is gone. Other times a whole 
section of the drive fails. But either way you are going to have to do a 
full reinstall, and configuring apps, and all that. Especially on windows 
with it's single file, prone to failure (because it gets written to so 
much), registry.

> I looked at Ghost and some others, but settled on Acronis True Image, as 
> it seemed to do what I wanted. Unfortunately, it appears that True Image 
> works best on a healthy drive and I was never able to get the image 
> copied (the status bar never moved... even after 24 hours).

Usually I try to use a failing drive as little as possible once it starts 
failing, it depends on what happened to it, but it's possible the more it's 
used the more failures you'll get. Maybe not - it all depends on what 
happened, which obviously you don't know.

> I thought perhaps since the drive I was copying from was IDE and the new
> one was SATA it could have been the problem.

Nah it won't make a difference which hardware type. But: the partition 
sizes need to match exactly or windows is going to get really upset!

> ddrescue -B -n /dev/hda1 /dev/hdb rescued.log

Looks semi-right. You are copying a partition to an entire un-partitioned 
disk. Windows will never be able to read that second disk (linux will have 
no problem though). You should have partitioned the second disk first - 
matching EXACTLY, to the byte, the partition size of the first disk. 
(Windows partition tools don't tell you how many bytes, use cfdisk, and 
switch to sector view, if you can't get it to match, you will need to 
change heads/sectors per track.)

Another thing: the file rescued.log - where are you storing it? ddrescue 
will store things in a ramdisk by default, but it's far from unusual for a 
dead disk to crash the computer - then you will lose the log!

Copy it to the floppy frequently!

Next time (!?) you do this, partition the new hard disk, part of it for 
the old data, and a small partition to hold the logfile.

> Current status 
> rescued: 5742 MiB,   errsize: 29612 KiB,   current rate: 2304 KiB/s
>   ipos: 5771 MiB,    errors:   595,       average rate:  140 KiB/s
>   opos: 5771 MiB
> Copying data....

> Does that look about right?  Seems to me at this rate (approx 5GB/day) 
> it's going to take about a month to complete...  am I reading this 
> wrong?

Yes, that looks right - it's very slow when it finds an error because it 
tries, over, and over, and over. Waaaaiiiting each time for the hard disk 
to try over, and .... you get the picture.

It'll speed WAY up once you get past the bad areas (well, that assumes the 
bad areas are in a clump).

BTW there is a patch to linux to make it not try multiple times each time 
it finds a bad sector. If you really need to you can try to find and use 
it. It's probably too much trouble though.

> 1. Copy the good data to a brand new HD (Copy1) using ddrescue. <-- This 
> is where I am now.

Looks good with the caveats I mentioned.

> 2. Attempt to copy from the bad sectors using ddrescue.

That implies running ddrescue again, using it's logfile, to re-try the bad 
sectors. OR at the very least running without the -n flag. Re-trying the 
bad sectors usually pointless. Removing the -n (which means splitting the 
bad areas, looks at each and every sector, trying to recover it), is 
probably a good idea. But potentially very time consuming.

> 3. Remove the failing HD and put aside.
> 3. Make another copy (Copy 2) from the first copy to another HD (Copy 3) 
> -- I'm assuming it would be OK if this new HD is SATA, right?

Yes it would be OK, and this is a VERY good idea. While you copy the data, 
this time, partition the new disk and copy the data to a partition. 
(You'll need to learn how to use dd and cfdisk.)

> 4. Use SpinRite (another recommended utility) to attempt to repair the 
> bad sectors on Copy 3.

Useless. There won't be an bad sectors on Copy 3 - there will simply be 
empty sectors. Unless you mean try to repair the _filesystem_ on copy 3 - 
that is an important step, and not an easy one.

After you are 100% sure there is no more recoverable data on the bad disk, 
then run SpinRite on the bad one - maybe, just maybe it will recover some 
more data. If it does you can ask ddrescue to give it another try and it 
will copy any sectors it can. I doubt SpinRite can do this though.

> 5. Attempt to repair WindowsXP with the repair utility on the install CD 
> (again, on Copy 3. In my perfect world, Windows would repair 
> successfully and I could find out which of my data files couldn't be 
> repaired and go from there.)

Sorry, but that aint gonna happen. You will have to reinstall fresh. Well 
- if you only end up with a very small number of bad sectors, then 
/maybe/, but otherwise you can end up with an executable that looks fine, 
but happens to have all zeros for 1 sector of it's code - it's not gonna 
be very happy about it, and I don't think windows provides any tools for 
figuring out WHICH files have bad sectors.

See, you have a list of bad sectors, but working out from that list, which 
files, is not simple. I know of tools with ext2 that will do it. I know 
it's impossible with ResierFS, I don't know about NTFS though, but I 
_really_ doubt it. (The computer knows what the mapping is, but no one 
wrote any tools to report it.)

> 6. If that won't work, I would install XP on a brand new drive and try 
> to copy the data files from Copy3 to the new install.

Yes.

> 7.  Identify what files didn't make it -- not sure how I'm going to do 
> that yet, but I'll cross that bridge when I come to it.

I wrote about that - maybe someone made a tool to do this. I haven't 
checked.

> 8.  Attempt to rescue those files specifically -- I'm not sure if I 
> should try off ofhe original disk or from one of the copies.

Won't help. You got what you can. If the data is not on the copies, it's 
just not there and there is no way to get it back.

I guess you could pay ontrak to try to recover the bad disk. It's 
expensive though, but depending on the data might be worth it to you.

> 9.  Once I'm satisfied I tried everything I could to get all the files I 
> need... I will probably run SpinRite on the original failed drive and 
> see what happens.

Yup.

        -Ariel