# Hard Drive failure

## Drantin

I have an ext3 formatted drive that I use with my laptop.  Recently, the drive powercycled while I was accessing it and then complained of a corrupted FS... I've tried various things to fix it, I thought I was on the right track using 

```
mkfs -S /dev/sdb1
```

 but running fsck to try to fix it fails after consuming all RAM and SWAP... 2GB RAM. 2GB Swap...

I do have another 10gig partition I was going to install win2k on and am trying using that in addition to the 2GB swap... but I have no idea if this will work...

Also, the drive is a 320GB SATA in a USB2.0 external enclosure.

Any other tips?

Anything I did that messed up the drive beyond recovery?

----------

## NeddySeagoon

Drantin,

I don't know what 

```
mkfs -S /dev/sdb1
```

does but hopefully its not harmful.

fsck, left to its own devices can do more harm than good. Its always a good idea to make an image of the partition before you start, so you have an undo capability. It may be too late now.

As its an ext3 partition, all the ext2 tools work read 

```
man e2fsck
```

Run 

```
e2fsck -n /dev/sdb1
```

from the liveCD (the partition must not be mounted) and see what happens. It will tell you what it wants to do but will do nothing. Post the first error you get.

Rule 1 with data recovery is don't do anything you can't undo.

----------

## wynn

NeddySeagoon *Quote:*   

> I don't know what
> 
> ```
> mkfs -S /dev/sdb1
> ```
> ...

 The omens are not good (mke2fs manpage)

```
       -S     Write  superblock and group descriptors only.  This is useful if

              all of the superblock and backup superblocks are corrupted,  and

              a  last-ditch  recovery  method is desired.  It causes mke2fs to

              reinitialize the superblock and  group  descriptors,  while  not

              touching  the  inode table and the block and inode bitmaps.  The

              e2fsck program should be run immediately after  this  option  is

              used,  and  there is no guarantee that any data will be salvage-

              able.  It is critical to specify the correct  filesystem  block-

              size  when using this option, or there is no chance of recovery.
```

----------

## Drantin

As it isn't my / partition and just used for data storage, (besides not having a livecd, nor capability to burn one here) 

I ran it straight from the laptop (the partition can't be mounted anyway... )

The first things that pops up is

```
e2fsck 1.39 (29-May-2006)

/dev/sdb1 contains a file system with errors, check forced.

Pass 1: Checking inodes, blocks, and sizes

Root inode is not a directory. Clear?no
```

Then after waiting a few minutes it jumps to displaying a large amount of numbers on the screen very rapidly, this is where top shows that the RAM and Swap are filling up.

Just tried it with the extra 10G swap and it failed, but much later in the fsck...

Also, sadly, I have no where to back up a 320G partition...

----------

## NeddySeagoon

Drantin,

It appears the the top level directory in the filesystem is damaged or corrupt.

Long shot - try 

```
e2fsck -n -b <alternate-superblock> /dev/sdb1
```

The numbers for <alternate-superblock> can be found in 

```
man e2fsck
```

and are filesystem block size dependant. If you get it wrong, its harmless.

wynn,

Does mkfs really default to an ext2 filesystem if you don't pass it a type?

I don't see anything in the man page.

----------

## bLUEbYTE84

You don't need 320 GB to back the partition up unless all 320 Gb is allocated in the partition (i.e bo free space).

Mount the partition to /xyz and just do a 'tar cvpf backup.tar /xyz'.

Then If desired, compress it with gzip backup.tar.

Then you will have a tar.gz backup with all the file permissions preserved.

Re-partition and reformat, and then restore with 'tar zxvfp backup.tar /xyz' or 'tar xvfp backup.tar /xyz' if it wasn't gzipped.

Don't forget the p argument.

P.S You use the term 'Hard drive failure' wrongly, you situation is not a hard drive failure as I understand, but rather a file system corruption. Hard drive failure is much worse than this  :Smile: 

----------

## NeddySeagoon

bLUEbYTE84,

Mounting and tarring requires the use of the filesystem, which is corrupt, so thats not an option.

You are right about the terminolgy, the drive appears ok, its the data stored on it that's damaged.

----------

## wynn

NeddySeagoon,

"Does mkfs really default to an ext2 filesystem if you don't pass it a type?

I don't see anything in the man page."

I assumed that mkfs would see that it was an ext2/ext3 and therefore choose to run mke2fs. Particularly in this situation where it is being asked to repair a filesystem.

(I feel a bit like a five year old in class being asked to explain something to the teacher   :Shocked:  )

----------

## bLUEbYTE84

 *NeddySeagoon wrote:*   

> bLUEbYTE84,
> 
> Mounting and tarring requires the use of the filesystem, which is corrupt, so thats not an option.
> 
> You are right about the terminolgy, the drive appears ok, its the data stored on it that's damaged.

 

Oops, you are right   :Embarassed:   :Razz: 

----------

## wynn

NeddySeagoon,

"Does mkfs really default to an ext2 filesystem if you don't pass it a type?

I don't see anything in the man page."

Yes, but my previous answer was wrong, it doesn't check the filesystem: if the argument "-t fstype" is not given it defaults to "DEFAULT_FSTYPE" which is defined as ext2.

(util-linux-2.12r-r4, disk-utils/mkfs.c lines 79-81

```
  /* If -t wasn't specified, use the default */

  if (fstype == NULL)

    fstype = DEFAULT_FSTYPE;
```

and lines 28-30

```
#ifndef DEFAULT_FSTYPE

# define DEFAULT_FSTYPE      "ext2"

#endif
```

so "yes" qualified by the Makefile flags not redefining it which it doesn't appear to do)

----------

## NeddySeagoon

wynn,

Thanks very much. 

Its not looking good for Drantins' data.

----------

## Drantin

Are there any good data recovery tools I could try if I get another drive to put the data on?

I've seen methods out there involving strategic use of the dd utility, but it seemed to be more for undeleting files...

Still, the data should be there, just innaccesible due to the part of the filesystem that's corrupted, right?

Btw, the drive was nearly full, with about 2G left free...

----------

## NeddySeagoon

Drantin,

If the drive is good but the data is corrupt, dd will be able to read it to make a copy.

You can test that by copying the partition to /dev/null

If the top level directory has been destroyed, you have lost the pointers to the lower level directories but if you can find one, you may be able to recover the data. I say 'may' because the 

```
mkfs -S ...
```

will have made things more difficult.

Reading the partition is harmless. Play with autopsy and testdisk but do not attempt 'in posiition' data recovery. Copy the recovered data to another partition. If you get really desperate there is debugfs and even hexedit. Debugfs is not intended for users - its a debugging tool. Read its health warnings before you allow it to write anything anywhere.

----------

## Drantin

Would file names still be able to be searched for, or are those lost along with the directory structure?

----------

## NeddySeagoon

Drantin,

Its only the top level of the directory tree thats missing - lower levels may still be intact.

How you make use of the lower levels, without the higher levels I'm not sure

----------

## Drantin

Well, I hav e been able to recover some files, albeit without names by using e2fsfind, it allows you to search for inodes with various restrictions, such as age, what they start with, etc. A found a portion of the AVIs on the disc by searching for all inodes that start with RIFF, I just need another HD now to dump stuff to, then a lot of time renaming and categorizing the collection...

----------

