On Wed, 26 Aug 2009 20:07:41 +0200, Roland Smith <rsm...@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, ...
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
