Re: dd hung up by disk errors
On Tue, 2009-07-21 at 23:27 +0900, Osamu Aoki wrote:
> On Mon, Jul 20, 2009 at 09:43:13AM -0700, Ross Boylan wrote:
> > I have a bad drive in a laptop and am attempting to salvage what I can
> > with (roughly)
> > dd conv=noerror,sync if=/dev/sda3 of=/nfs/backup
> > where the of is NFS mounted from another system.
> >
> > This keeps trying when it encounters a disk read error, but there are
> > lots of errors and it is very slow (only 200MB transferred in c 9
> > hours). The first 62G went OK, but the disk is c 75G.
> >
> > I'm willing to accept some sectors as lost, but it would really help if
> > there were a way to do so quickly. Is there?
> >
> > I think the drive is SATA; it's in a Dell Latitude D630 laptop. I
> > booted off a Knoppix 5.1 CD. sda3 is an NTFS partition.
>
> As others has noted, use of dd with seek etc. will do most.
>
> I have made list of data recovery tools on Debian.
> http://www.debian.org/doc/manuals/debian-reference/ch10.en.html#_data_file_recovery_and_forensic_analysis
> This may help later.
Thank you very much for making that available, and thanks to the other
posters for their suggestions.
>
> Anyway, your harddisk may be faulty. It sounds like to get new one.
The drive reports it has already failed. I have a new one, but am
trying to salvage what I can. I haven't tried to transfer the bad drive
to a new enclosure because I anticipate it will fail completely soon.
>
> If I were you and I have minimum budget and hardware (I mean no extra
> PC), I will go buy new SATA disk and external SATA/USB kit.
I have a newer, bigger laptop disks and am backing up to my main hard
drive.
Some tidbits:
Initially I transferred using something like
dd conv=noerror,sync if=/dev/sda3 | ssh bigcomputer "cat > sda3.image"
I didn't realize that stdin could be directed across the network like
this. However, this imposes the overhead of ssh.
I had
/usr/local/backup/cotton
192.168.40.0/24(insecure,sync,rw,no_subtree_check,all_squash,anonuid=1000)
in /etc/exports, but my initial attempts to mount failed with some error
talking about "bad superblock".
The fix was to mount with -o nolock.
Also, I tried piping through bzip:
dd conv=noerror,sync if=/dev/sda3 | bzip2 | ssh ....
However, this gave me lower throughput (in terms of bytes of the
original file). And for some reason, the compression was pretty
effective on my other partitions (e.g., 10% of original size) but quite
ineffective with the Vista file system (about 2/3 of original size).
The Vista partition is relatively full of real data (much of it my
daughter's music files, which I guess are already compressed), but still
this was a little surprising. The partition is not encrypted. All the
other partitions seem to read without error.
Finally, I think my choice of block size was suboptimal. I got at best
20MB/s on Gigabit ethernet, on which I would hope for around 100MB/s.
With bzip2 the compression was clearly the limiting factor. I suspect a
larger write block size, and maybe a larger read block size, would have
helped.
I did some earlier backup to a SAMBA share; that method too had pretty
dismal throughput, even given that was on 100Mb ethernet.
Some of the rescue programs say they try big blocks first and then back
down to smaller ones if there is an error, in hopes of getting the most
sectors possible.
I suppose one "advantage" of larger input block sizes is that they
reduce the number of attempted reads, and so get you through the bad
spots faster--at the cost of possibly missing some readable sectors.
Ross
>
> 1. Buy 500GB SATA at below $100 (160GB below $50)
laptop disks are a little pricier.
> This should be enough space.
> 2. Do fresh install. (Both NT/XT and Debian)
> 3. Put old disk on USB box and work on data recovery.
>
> Osamu
Reply to: