copying a disk with ignoring errors

[Christoph Kukulies]

Am 05.07.2010 21:39, schrieb Polytropon:
> On Mon, 05 Jul 2010 16:09:23 +0200, Christoph Kukulies<kuku at kukulies.org>  wrote:
>    
>
>> I tried PHKs' recoverdisk with  recoverdisk -b 1024000 /dev/ad2 ad2.dmp
>>
>> and it went off quite promising just few dma read timeouts and when I
>> was at 7% of recovery
>> it suddenly says:
>> ad2: FAILURE - device detached.
>> 1558528000 1024000 failed (device not configured)
>> #
>>      
> Not good. Can you obtain an 1:1 copy of the disk using ddrescue?
> And it's often easier to operate partition-wise, if there are
> functionally separated partitions on the disk; let's assume
> the /home directory was mounted from slice 1 partition f, then
> try:
>
> 	# ddrescue -d -r 3 -n /dev/ad2s1f home.ddr logfile
>
> If you are lucky to get a copy of this partition, you can try
> to apply analytic and repairing tools to that partition copy.
>
>
>
>    
>> Hmm. How can I avoid that the device gets detached?
>>      
> I do not think you can do anything against it. A device detachment
> means a MASSIVE failure. It *can* be a problem of the controller,
> but mostly it is a problem of the disk itself. There can be a way
> to get around it - by replacing the disk's PCB with an identical
> one. But it's not for sure that this will work, e. g. if the disk's
> drive components have massive defects.
>
> A device detachment at least doesn't look like an "easy" I/O problem
> within the drive's components (the platters, heads, the motors).
>
> The error must be that massive that the disk itself says goodbye
> to the system and disappears so that no control commands will reach
> it.
>
> You can try "atacontrol reinit" to force the disk back on-line,
> but it may refuse to do so. See "man atacontrol" for other options.
> You can also use the "smartctl" program (from port "smartmontools")
> to check the drive's error memory to see what has caused the detachment;
> maybe there's some information there.
>
> It's like /dev/cpu: device disappeared. :-)
>    

Thanks for the detailed alternatives and explanations. I managed in a 
second attempt
by using the option recoverdisk -b 102400 -r workfile -w workfile 
/dev/ad2 ad2.dmp
(maybe I was using a different large number for the -b option, maybe I 
even tried it once with -b 0).
Anyway the second time it held until I was down to a few thousand block 
being unrecoverable.

In the end I was able to recover the data. Thanks.

Christoph