Re: Trimming away bad sectors...

["Robert G. (Doc) Savage" <dsavage@peaknet.net>]

On Sun, 2004-11-21 at 16:23 -0600, mike808@users.sourceforge.net wrote: 
> >From the webpage:
> > The current version is 1.10.
> > Since 1.10, it has support for non-seekable input and output
> > (so you can write to pipes, e.g. stdout). 
> 
> Looking through the source code, you can see that you can use the special 
> filename '-' (dash) for the output filename to send the output to stdout.
> 
> So, your example source should be changed to:
> 
>    # dd_rescue if=/dev/hda5 - | nc 192.168.1.2 30000 -w 3
> 
> And you should be good to go. Let us know how it went. However, due to the
> non-seekable nature of the STDOUT character device, you will not be able to
> run "partial" or a reverse dd working with a target file to fill in the missing areas you're ripping from the bad disk.
> 
> Another poster also mentioned NFS/SMB mounting as well. But, if you're doing this via remote connection into the box, netcat is a heck of a lot simpler than firing up SMB/NFS servers and clients. I assume you're tunnelled through SSH (or you could setup a port forward and then use netcat to send it to the local forward, tunnel it back through SSH, and then receive it with nc on your remote console.

Mike,

The more I thought about Casey's suggestion, the more I warmed to it.
True, setting up NFS is a bit of a bother. But it's not really all that
difficult. You're right about any errors being unrestorable. That's why
I've decided to create a tarball along with the raw image file. That way
I'll at least know what file(s) got munged.

I have a feeling that instead of seeking out and analyzing a hacked PC
for my SANS forensic certification, I just might write a paper on the
use of dd_rescue in cases like this. There may yet be a silver lining
around this dark cloud....

I set up a local NFS export of the large array's /pub/images directory
and mounted it to /mnt/images on my laptop. Then I started a dd_rescue
session:

  # dd_rescue -v -l /root/hda5xfer.log if=/dev/hda5 \
      of=/mnt/images/hda5_rescue.img

Everything began nominally and proceeded just a tad bit slower than the
earlier dd sessions. Then WHAM!! When it hit the bad sectors at the 9.8G
mark my poor old laptop ground to a halt like a charging dog reaching
the end of its leash. For all intents & purposes, dd_rescue took every
available CPU cycle and locked up my X displays completely. It crawled
through 153 very long bad sector loops before it suddenly came back to
life.

My listener system chose that exact instant to throw a CPU #0 error with
an alarm buzzer, and locked up tighter than a tick. It dropped off the
instant I touched the power button, so it was in bad shape.

It's taking quite a while to bring it back up. In the first attempt it
apparently couldn't find & mount the swap partition. The second time it
got a little farther: "Your system appears to have shut down uncleanly"
No shit Sherlock. I told it "y" to run a filesystem integrity check
on /. It did that and successfully restored the journals for the /boot
and /pub partitions. It appeared to stall after fsck'ing the /boot
partition. Another hardware reset... This time I payed closer attention
and noticed that the apparent stall was actually the system fsck'ing the
1T /pub large drive array. It's currently putting on a great light show.

Anybody care to guess how long it takes to fsck a 1T drive at boot time?
(Answer: ~22 minutes.)

So after the smoke clears I'll run dd_rescue again. I have a feeling
this might be a v-e-r-y long night. After I've got all partition images
safely onto the large drive array, I'm going to haul out my new hard
drive toy and do a low level re-format of that 48G drive. It'll map out
any bad sectors it finds, and re-certify it to "like new" condition.
Some time tomorrow night I should be ready for a bare metal restoration.

--Doc


-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.