Hello, I recently bought an external hard-drive/NAS which unfortunately had a rather dodgy power cable connection - a few accidental power interruptions later and I have one hard-drive containing all of my most precious data in a totally inaccessible state.

I had formatted the drive as EXT3 under Ubuntu (via a usb cable to the NAS), then copied over several hundred gigabytes of data via FTP (as my mac could not access the samba share properly, and could only mount the NFS share read-only).

I booted into Ubuntu and had a go at evaluating what was wrong with the drive, gparted was unable to read a valid filesystem - I had read up on repairing the filesystem a few days ago and attempted this with fsck, I don't think I actually did anything though - my understanding of how to use it was pretty limited. I did get an error regarding a "bad superblock". I understand it's fairly easy to mess the filesystem up even more if you don't really know what you are doing.

I do not know what I am doing.
So, I have come seeking wisdom.

What would be the best way to recover the EXT3 partition without losing the file-structure (directories etc.)?

EXT3 creates many backup superblocks, try using one of the backups to repair the filesystem.

I'll use /dev/hdaX as the example drive, substitute your own drive here.

Get a list of the backup superblocks:
sudo dumpe2fs /dev/hdaX | grep -i superblock

Fix the filesystem using e2fsck, providing it with a backup superblock (32768 in the example) via the -b option:
sudo e2fsck -b 32768 /dev/hdaX

That should be it.

Here is a sample output of dumpe2fs listing the superblocks.

sudo dumpe2fs /dev/hda2 | grep -i superblock
dumpe2fs 1.41.6 (30-May-2009)
Primary superblock at 0, Group descriptors at 1-3
Backup superblock at 32768, Group descriptors at 32769-32771
Backup superblock at 98304, Group descriptors at 98305-98307
Backup superblock at 163840, Group descriptors at 163841-163843
Backup superblock at 229376, Group descriptors at 229377-229379
Backup superblock at 294912, Group descriptors at 294913-294915
Backup superblock at 819200, Group descriptors at 819201-819203
Backup superblock at 884736, Group descriptors at 884737-884739
Backup superblock at 1605632, Group descriptors at 1605633-1605635
Backup superblock at 2654208, Group descriptors at 2654209-2654211
Backup superblock at 4096000, Group descriptors at 4096001-4096003
Backup superblock at 7962624, Group descriptors at 7962625-7962627

I hope that helps you out.

but dump2fs works only if it can found the first superblock or can recognize the correct fs.
but with mke2fs -n you can see the "planned" superblocks without writing anything to the disk.

Anyway, backup the entire drive (all sectors) before any fsck attempt!

Janos

Agree 100% with Janos. Work on Image not on patient drive!

I'm not at all sure how possible this would be, I don't know how much data I had transfered to the hard-drive before it failed. Would there be a way to determine the amount of data stored in the partition and then create a backup image which would only take up that much space? The drive in question is a 1TB drive, and I don't have a spare 1TB laying around to house an image on - I do have a 500GB, though.

Need an identical or larger drive to image - block by block / sector copy.

In which case, I'll order a new drive.

Thanks for your help.

Okay, unfortunately I'm not in a position to make the backup so I've decided to just go ahead and attempt to fix the filesystem (or accept the loss of my data and move on).

I've just used:
sudo dumpe2fs /dev/sdc | grep -i superblock

Which returned:
demp2efs 1.41.4 (27-jan-2009)
dempe2fs: Bad magic number in super-block while trying to open /dev/sdc
Couldn't find valid filesystem superblock.

Help?

If you have PC with Windows - try to scan the COPY of the drive with R-Studio

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

hi, i have the same problem with the EXT3 filesystem unuseable - Bad Superblock ...

did the e2fsck -b 32768 /dev/hdaX

then gave me this msg:

e2fsck 1.41.4 (27-Jan-2009)
e2fsck: Bad magic number in super-block while trying to open /dev/sdb5

The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>

any ideas how get this right?

I also had superblock corrupted, I found a working one with help of e2sl utility. I had to tweak it a little bit to force it not to display false-positives. But after that the rest was easy.

See the attachment for the corrected source code of this program.