From owner-freebsd-questions@FreeBSD.ORG Wed Aug 26 23:04:00 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44B54106568B for ; Wed, 26 Aug 2009 23:04:00 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) by mx1.freebsd.org (Postfix) with ESMTP id C6E1D8FC22 for ; Wed, 26 Aug 2009 23:03:59 +0000 (UTC) Received: from r55.edvax.de (port-92-195-1-225.dynamic.qsc.de [92.195.1.225]) by mx01.qsc.de (Postfix) with ESMTP id CBDC33CBDD; Thu, 27 Aug 2009 01:03:59 +0200 (CEST) Received: from r55.edvax.de (localhost [127.0.0.1]) by r55.edvax.de (8.14.2/8.14.2) with SMTP id n7QN3wCh002851; Thu, 27 Aug 2009 01:03:58 +0200 (CEST) (envelope-from freebsd@edvax.de) Date: Thu, 27 Aug 2009 01:03:58 +0200 From: Polytropon To: Roland Smith Message-Id: <20090827010358.121fa496.freebsd@edvax.de> In-Reply-To: <20090826180741.GA23120@slackbox.xs4all.nl> References: <1338880b0908241129p75b6845cg26d21804e118364@mail.gmail.com> <20090824223247.GD43410@slackbox.xs4all.nl> <1338880b0908252246s21191e83k7c251366b706532@mail.gmail.com> <20090826180741.GA23120@slackbox.xs4all.nl> Organization: EDVAX X-Mailer: Sylpheed 2.4.7 (GTK+ 2.12.1; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Kelly Martin , FreeBSD Questions Subject: Re: hard disk failure - now what? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Polytropon List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 23:04:00 -0000 On Wed, 26 Aug 2009 20:07:41 +0200, Roland Smith wrote: > If the drive is that bad, it is doubtfull if dd or ddrescue will be able to > get a good copy. There's an additional problem: Let's assume dd creates an 1:1 copy of the file system in its actual state - nobody guarantees that this file system is fully intact, or can be repaired. I have (!) the problem myself that I got the dd copy from the partition holding my home directory just fine, but the file system itself is damaged in such a state that fsck_ffs cannot repair it. At least, I could get data off it - EXCEPT my home directory, sadly. But that's not a (physical) disk problem, but a file system related one. > Using dd you make a block-for block copy; dd doesn't know about filesystems. > You could pipe the output from dd through a compression program like gzip or > bzip2. That could yield a smaller image. But you'd have to uncompress it in > order to use it. I'm often told that hard disks are cheap today, and it's much more relaxing operating on a plain image than on a compressed one. > Or you could try just copying the filesystems separately. E.g. copy from > ad4s1f instead of the whole ad4. That way you can split the data over several > files which you can store in different places. That is the encouraged method. In case you have separated file systems, it's a quite optimum case. For example, you don't need to mess around with a 20 GB /tmp partition if you intendedly want to lose its "data". > I hope you get a good copy, but it doesn't sound too likely. I'm not a hardware > expert, but if the disk is really breaking down in the hardware or > electronics, it is not inconceivable that even reading might further > deteriorate it. In case of such hardware defects that causes growing problems, it's wise to get the data (1st) as fast as possible and (2nd) as accurate as possible - before the disk completely dies. In such a case, it's still possible to recover data, e. g. to mount the disks (the cylinders or platters) into another drive unit. But if the disks are defective theirselves... > If you do not get a good 1:1 copy, you'll have extra errors in > your data! Depending on the options you give dd, it will either skip blocks > with errors or fill it with zeroes or other characters. See the piece of the > manual page of fsck_ufs that describes the 'noerror' conversion. As far as I remember, dd_rescue or ddrescue can handle such problems. In case of errors, they retry and keep reading. > > fsck_ufs: cannot alloc 4294967292 bytes for inoinfo > > The meaning of errors is explained in Appendix A of "Fsck - The UNIX File > System Check Program". You can find it this as > /usr/share/doc/smm/03.fsck/paper.ascii.gz When I tried to repair my defective partition in another system with less RAM, I got a similar error: cannot alloc 1073796864 bytes for inoinfo The real ("usual") error is fsck_4.2bsd: bad inode number 306176 to nextinode It seems that more RAM is needed to store information. > Time to start thinking about a solid backup strategy as well. :-) The correct time to do so is BEFORE you start storing data. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...