Date: Tue, 06 Jul 2010 12:43:30 +0200 From: Christoph Kukulies <kuku@kukulies.org> To: freebsd-questions@freebsd.org Subject: Re: copying a disk with ignoring errors Message-ID: <4C3308D2.6000704@kukulies.org> In-Reply-To: <20100705213953.b56c3e01.freebsd@edvax.de> References: <4B434D52.3030301@kukulies.org> <20100106023007.b3a19517.freebsd@edvax.de> <4C31E793.3040000@kukulies.org> <20100705213953.b56c3e01.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 05.07.2010 21:39, schrieb Polytropon: > On Mon, 05 Jul 2010 16:09:23 +0200, Christoph Kukulies<kuku@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C3308D2.6000704>