[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Harddisk gone bad (longish)

> On Sun, Nov 10, 2002 at 08:55:26PM +0100, Francesco Peeters wrote:
> I suppose one of these days someone really should write a "hard disk
> catastrophe" HOWTO.....

That'd be cool!

> When you have a lot of precious data on a disk that hasn't been backed
> up.  The very **first** thing you should do is to get the cursing
> yourself for being twenty different kinds of full for not having a
> backup system out of your system.  Get that out of your system, so you
> don't make any further mistakes.....

LOL... Done that!!!
> Next, get yourself a backup hard drive which is at least as big as the
> disk which is in trouble, and do a full disk-to-disk copy of the disk
> that's in trouble:
> dd if=/dev/hdc of=/dev/hdd bs=1k conv=sync,noerr
> Do this right away, because if the problem was due to hardware
> failure, you want to grab a snapshot before the disk gets any worse.

That's happening right now...

> For experimental purposes, if you're not sure what you're doing, it's
> useful to get another spare disk, and make a second-generation copy
> from your first primary backup.  That way, you can experiment on the
> second-generation copy, and if one recovery technique doesn't work,
> you can try again with a different technique, and not have to worry
> about making any irrecoverable mistakes.

Was planning on doing that as well.... Waiting for a 2nd drive &
controllercard to arrive this week... I'll then implement (hardware) RAID1
when all data has been retrieved... (or found irreparably lost!)

> The first thing I would try at this point, is an "e2fsck -y" on the
> second generation backup.  See what you can save when it's all done;
> don't forget to check the lost+found directory in the root of the
> filesystem.  Sometimes files will end up there.
> If that doesn't work, the next steps will require a lot more expertise
> and special work.  So I'd start with that, and see how much you can
> recover from that.
> > Now when I try to do e2fsck /dev/hdc1 I get 'a corruption was found
> > in the superblock' When I try e2fsck -b 8193 /dev/hdc1 It claims it
> > is not a valid superblock... The same for for instance 32679, a.s.o.
> For a 4k filesystem, the backup block is 32768.  But please, make the
> full disk-to-disk backups first, and experiment on the backups.  That
> way, you don't need to worry about panic-induced mistakes from making
> the problem any worse.

Oops! That was a typo... I meant 32768... Anyway, it didn't work... That is
the real problem!  :-( But I didn't want to go on without a backup

> - Ted
> P.S.  For those people for whom backups are just too much effort,
> *please* consider using the "e2image" program to snapshot and backup
> critical filesystem metadata.  It's not a replacement for doing full
> data backups, but at least if you have an e2image dump, in the worst
> case you'll be able to recover more files if a disk failure damages
> your inode table.  The problem without the inode table there is no
> record of which blocks go with which files, which means that
> recovering files because a very, very painful manual process.  e2image
> will create a backup copy of the inode table, which even if it is not
> fully up-to-date, will be a help in trying to reconstruct data from a
> filesystem after a disk failure.  Of course, the real answer is to do
> real backups.....

Until I can afford a backup system that can effectively backup all live data
(prolly gonna be an onstream drive for price/performance reasons) would it
be possible to run e2image from cron on a daily basis?



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]