On Thu, Aug 27, 2009 at 01:03:58AM +0200, Polytropon wrote:
> 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.

Certainly. If filesystem data is missing, there is only so much that fsck_ufs
can do about it.
> > 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.

Of course. But if you are operating under restricted scape constraints...

> > 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.

And (3rd) in as few tries as possible!

> 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...

I wonder if that is still possible with current drives? My impression was
(from a paper that I can't locate ATM) that data densities are so high that it
is extremely difficult to read the data with different arm/head assembly then
the one it was written with.

> > Time to start thinking about a solid backup strategy as well. :-)
> The correct time to do so is BEFORE you start storing data. :-)

Very true! But since the lack of backups was what got the OP in this mess in
the first place...

R.F.Smith                                   http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)

Attachment: pgpuFA9QD2zWP.pgp
Description: PGP signature

Reply via email to