PLEX86  x86- Virtual Machine (VM) Program
 Plex86  |  CVS  |  Mailing List  |  Download  |  Linux  |  Newsgroups

recovering data from a crashed ext3 hard disk 4809


Your Ad Here

Your Ad Here

On Fri, 16 Sep 2005 15:45:41 -0700, devs

DON'T DO ANYTHING ON THAT DISK!! STOP IMMEDIATELY!!

I've just been through this exercise, although my parbreastions were all reiser. In a nutshell, here is what I did - BTW the first thing you should do is shut it off until you get a new drive installed. Attempting to fsck a crashed disk will not do anything good.

recovering data from a crashed ext3 hard disk 4811
Walter Mautner I know: my tape drives cost more than the average computer these days. But...
Thttpd web server and symbolic links 4813
According to Google Groups, this alias has only posted 201 times in the last year. Not likely for...

what I did: 1) buy a new disk at least as big and install it. New drive is hda old crashed drive is hdb

2) installed linux (from elive live CD) - this is optional as you can work from a live CD if you wish, but you'll need to create some parbreastions to hold the data anyway. In my case both were 80 gb disks. On the new one, I set up about 10gb parbreastion for elive, 1gb swap and 65gb data parbreastion.

3) boot to linux

recovering data from a crashed ext3 hard disk 4810
Jean-David Beyer unfortunately the OPs posting isn't yet available on Google groups and it fell through my filter You will want ddrescue. It's on any recent knoppix live...

4) do the following for each parbreastion on the destroyed hard disk: dd if=-dev-hdb of=-mnt-data-nameofparbreastion skip=nnnn count=nnnn conv=noerror conv=sync NOTE: skip=nnnn gives the starting block of the parbreastion and count=nnnn gives it's length. I had to do this because the parbreastion info was lost as well. If it's still there you can probably just do if=-dev-hdbN where N is the parbreastion info. If the info is lost you can (probably) recover it with sfdisk 'sfdisk -Vl -uSdev-hdb'. You NEED noerror to keep the dd going past bad blocks and you need sync to throw in the appropriate number of zeros when it reads a bad block, otherwise the data will get hopelessly scrambled.

5) make a copy of the parbreastion image

6) mount the parbreastion image: losetupdev-loop0mnt-data-copyofparbreastionimage mountdev-loop0mnt-loop

7) Now you can fsck the copy of the image. I found that I didn't even need to do that as reiserfsck --check indicated that it was fine.

8) at this point I was able to copy all the data.

It seems in my case it was mostly the mbr and parbreastion 12 that were affected. There were 68 plus 11 bad blocks in 14gb of data, and every file I attempted to recover was good. The other parbreastions were no problem.



Your Ad Here

List | Previous | Next

recovering data from a crashed ext3 hard disk 4810

Linux groups from Newsgroups

The #1 Usenet Provider on the Internet

kernel upgrades and kernel driversmodules dependancies question 4808