ext3 corrupted

Marc Lijour marc-bbkyySd1vPWsTnJN9+BGXg at public.gmane.org
Tue Jul 24 01:53:52 UTC 2007


> John Van Ostrand wrote:
>> On Sat, 2007-07-21 at 17:37 -0400, Marc Lijour wrote:
>>
>>> I have a drive that got corrupted (just before it started to send SMART
>>> alerts). I can't mount it and I get this error message:
>>>
>>> EXT3-fs error (device sda12): ext3_check_descriptors: Block bitmap for
>>> group
>>> 896 not in group (block 16777317)!
>>>
>>> I can't mount it as ext2 either, and I can't mount sda either. auto as
>>> type
>>> does not work either.
>>>
>>> Running fsck and accepting all actions with a 'y' seems to have no
>>> effect. I
>>> can't mount the disk and when I get to do fsck again I get the same
>>> actions.
>>>
>>> dd works.
>>>
>>> Do you know a way to get the data back?
>>
>>
>> First, let the drive cool down. Sometimes heat and the expansion of the
>> platters can cause read errors.
>>
>> Next, get another drive and perform a dd from the dying drive to the
>> working drive. I would recommend booting from a rescue CD. Disc 1 from
>> any Red Hat/Fedora/CentOS will act as a rescue CD by typing "linux
>> rescue" at the boot prompt. Ubunutu's live boot would work as well and
>> give you some GUI tools too. Use the 'noerror' option when using dd so
>> that disk read errors will not abort the copy.
>>
>> If the data is particularly sensitive you may want to make another copy
>> before continuing.
>>
>> I can't comment on the tools to use to fix that file system, fsck has
>> generally worked for me. If you don't want to get your hands dirty there
>> are labs that will restore the data for you by working a little harder
>> to correct the file system errors.
>>
>> Good luck.
>
> These are good suggestions, specially the 'dd' one.
>
> One trouble with any journaled file system is that data recovery is very
> difficult. An ext2 partition is simple to recover, by comparison. It's
> to the point now where if I have an ext3 (or other journaled) FS, I get
> paranoid about backups. My personal view/experience is that it's just
> not possible, but I am also not an expert.
>
> I would suggest that, if your data is critical, do not attempt anything
> beyond the 'dd' yourself.
>
> Ontrack (http://www.ontrackdatarecovery.com/ontrack) was the DR house
> I've used in the past. They're very talented, and recovered a physically
> defective drive a client had (whose tape backup had silently failed,
> ending my trust of tape backups ever since). I believe it was about
> $1,700 and they were unable to recover the directory structure, but all
> the data was there. It took about two more days to recreate the
> directory structure, but in the end we got all the data back. I believe
> they will look at your drive and give you an idea of the likely hood of
> recovering your data before doing billable work. At least they did back
> when I last needed them.
>
> I would *only* suggest trying anything further on your defective disk if
> you get a quote from them (or another DR house) and you decide it's too
> expensive (ie: 'nothing to lose'). If you do manage to make a dd image,
> try doing data recovery on a copy of the image. You really do not want
> to touch the source drive *any* more than you have to.
>
> I wish I had better news. :( Journaling is a double-edged sword.

Thank you for all these great tips. It's hard to keep up with the mail
with one less computer ;)

I have 2 disks. My data is one the drive which failed. I commented it out
from /etc/fstab and I stopped using it. Now the second drive seems to be
failing. I even got the BIOS not founding the drives at boot time once.
Which makes me wonder if the problem does not come from the board.

In any case, I have a technical question about dd. My data is on
/dev/sda10 (around 100GB). Say I plug another SATA drive (say a new 500GB
drive). How should I proceed? I assume I should first create a partition
with exactly the same size (or a little more) on the new drive, and then
run dd. Is that correct? At that point, you'll understand I take no chance
with my data ;)

Thanks
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists





More information about the Legacy mailing list