Date: Thu, 27 Aug 2009 01:03:58 +0200 From: Polytropon <freebsd@edvax.de> To: Roland Smith <rsmith@xs4all.nl> Cc: Kelly Martin <kellymartin@gmail.com>, FreeBSD Questions <freebsd-questions@freebsd.org> Subject: Re: hard disk failure - now what? 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 26 Aug 2009 20:07:41 +0200, Roland Smith <rsmith@xs4all.nl> 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, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090827010358.121fa496.freebsd>