Tell me more ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.
up vote 1 down vote favorite
1

My company has a server with one big partition with Mysql database and php files. Now this partition seems to be corrupted, as reported from kernel messages when I tried to mount it manually:

[329862.817837] EXT3-fs error (device loop1): ext3_check_descriptors: Block bitmap for group 1 not in group (block 0)!
[329862.817846] EXT3-fs: group descriptors corrupted!

I've tried to recovery it running tools from a PLD livecd. These are the tools I have tested: - e2retrieve - testdisk - photorec - dd_rescue/dd_rhelp - ddrescue - fsck.ext2 - e2salvage without any success. 

dumpe2fs 1.41.3 (12-Oct-2008)
Filesystem volume name:   /dev/sda3
Last mounted on:          <not available>
Filesystem UUID:          dd51610b-6de0-4392-a6f3-67160dbc0343
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal filetype sparse_super
Default mount options:    (none)
Filesystem state:         not clean with errors
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              9502720
Block count:              18987570
Reserved block count:     949378
Free blocks:              11555345
Free inodes:              11858398
First block:              0
Block size:               4096
Fragment size:            4096
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         16384
Inode blocks per group:   512
Last mount time:          Wed Mar 24 09:31:03 2010
Last write time:          Mon Apr 12 11:46:32 2010
Mount count:              10
Maximum mount count:      30
Last checked:             Thu Jan  1 01:00:00 1970
Check interval:           0 (<none>)
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
Journal backup:           inode blocks
dumpe2fs: A block group is missing an inode table while reading journal inode


e2fsck 1.41.3 (12-Oct-2008)
fsck.ext3: Group descriptors look bad... trying backup blocks...
fsck.ext3: A block group is missing an inode table while checking ext3 journal for /dev/sda3

I tried also backup superblocks, same error result.

There's any other tools I have to test before considering these disk definitely unrecoverable? Many thanks, ip

share|improve this question
What did you get from fsck.ext3 ? What's the output like? What are the error messages? – wazoox Apr 12 '10 at 10:31
Added e2fsck output above, thanks – ip Apr 12 '10 at 12:13
tell me what the optimal fs block size for the database thanks! – user68423 Jan 27 '11 at 8:45
@DieselxXx - this is not a forum, please read our FAQ before 'answering' again. – Chopper3 Jan 27 '11 at 8:46

2 Answers

up vote 0 down vote

It looks like your inode table is messed up. Try the following:

  • Boot from a live disk and mount the partition. If successful, backup your files.
  • Convert back to ext2 using tune2fs, run e2fsck, remount, backup your files.
share|improve this answer
All output above come from a livecd (rescuecd.pld-linux.org). "tune2fs -O ^has_journal" returns "A block group is missing an inode table while reading journal inode" error message. Thanks – ip Apr 12 '10 at 13:25
What were the events leading up to the failure? Did this occur after a reboot, power outage or BIOS update? If you haven't already, I suggest you backup this device immediately before attempting any repairs. – Melvin Apr 12 '10 at 13:40
Too late, I think. I cannot mount this partition and my colleagues report disk failure without any noticed external action or event. Running a low level "dd if=/dev/sda3 of=/dev/null oconv=noerror" reports bad blocks at the middle of scan (about 5Mbyte on 78Gbyte total size). Of course, this server was not considered "mission critical" until it failed :-) (no backup) – ip Apr 12 '10 at 13:55
no backup, no raid? wow, that's a fsck up if ever i saw one. try doing a dd=if/dev/sda3 of=backupfile and then running fsck against that without the badblocks, it may get the files system up and running again. I've found fscking drives with bad physical blocks can take ages and also fail!!! backup up the drive. You could always try the freezer trick, which has also worked for me in the past. – The Unix Janitor Apr 12 '10 at 15:15
thanks for your suggestions,I've tried it with no success. I tried also with ddrescue and dd_rhelp. fscked dd* images always returned errors as stated above: "A block group is missing an inode table while checking ext3 journal for /dev/sda3". Is it definitely dead? – ip Apr 12 '10 at 16:30
up vote 0 down vote

I've not recovered from an ext3 failure in a while, but, isn't there an option to tell fsck.ext2 to use a secondary superblock?

-b superblock

man 8 fsck.ext2

With that, you MIGHT be able to get it to repair or at least traverse the tree. Depending on the value of the data, the more you work with it, the worse the chances of a recovery company being able to salvage the data.

I wouldn't actually write data and would suggest mirroring the drive to a file/identical disk before doing too much damage. Depending on how valuable the data is, ontrack.com can recover data (they are slow but two drives we had recovered for clients this year came back with 95% of the data intact - at about $3k each)

share|improve this answer
You are right. Most of my attempts was done on images in a second drive created by dd or dd_rhelp or ddrescue. Also I've tried alternative superblocks, but still without success, I cannot mount it nor traverse the tree. – ip Apr 13 '10 at 7:17

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.