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... Roland -- 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)
pgpuFA9QD2zWP.pgp
Description: PGP signature