LinuxQuestions.org - Recover corrupt partition

- Linux - General (https://www.linuxquestions.org/questions/linux-general-1/)

- - Recover corrupt partition (https://www.linuxquestions.org/questions/linux-general-1/recover-corrupt-partition-661862/)

Recover corrupt partition

Ok, I ran into a serious problem recently. I moved my HD to a new computer and it was shown as "BAD". So I moved the HD back to the original computer and started showing some bad signs. I couldn't mount my /home partition due to numerous errors. So naturally I ran fsck on the partition. The fsck went on to prompt to fix thousands of errors. I ctl+c the fsck part-way through and used ddrescue to copy the HD over to a new HD. I then proceeded to run fsck -y on the original /home partition to completion. It appears that it placed ALL of the files in /home/lost+found, as opposed to only some of them. This makes it almost impossible to sift through all of the data and re-organize them. Is there an easier way to do this?

There's an interesting thing about my particular case. I normally run Gentoo Linux, and prior to running fsck, I chrooted into Gentoo (from Ubuntu, where I ran the fsck) and I could use the /home just fine.

Timeline:
Move HD to new computer
Received BAD from BIOS
Moved HD back to old computer (dual-booting Ubuntu and Gentoo)
Tried booting into Gentoo, failed
Booted into Ubuntu
chrooted into Gentoo, found everything worked
Ran fsck on all partitions, /home is the only partition with errors
Ran fsck on /home, received thousands of errors
Cancelled fsck
Copied /home to a new HD using ddrescue
Continued with fsck on /home using -y

So essentially what I want to ask is if there's any way to recover my files on /home without destroying the directory structure?

There are some distro's on sourceforge that have forensic tools that might help. Try searching for "data recovery" in slashdot for projects like this one:
http://sourceforge.net/projects/dr-tools/

For some of the documents in your lost&found directory, you can use the file command to find out what kind of file it is.
For example, here I'm looking at the firefox Cache/ files sorting out just the jpeg files and stripping out the extra info on the line.
file * | grep JPEG | sed 's/:.*$//'

I could use these filenames in a for loop and add .jpg to the end:

Code:

for picture in $(file * | grep JPEG | sed 's/:.*$//'); do

  mv "$picture" "${picture}.jpg"

done

You could then copy them into a "jpegs" directory for example and then use find to remove very small jpegs that are probably from an icon cache:
find jpegs/*.jpg -size -10K -exec rm '{}' \;

Now the number of files may be more reasonable you can preview them in konqueror or gwenview and delete more of the junk.

Next, do the same for pdf files. You can enable previews of pdf files in KDE. This can help to see the titles and rename them without even opening them.

I just responded in another post where someone zeroed out their mbr. You might try mounting the ddrescue image, if it is mountable.

If this is an image of the drive and not the partition, you can use losetup to mount a partition that is in the drive image file. You just need to know the offset. If the mbr is intact, run "fdisk -lu <imagefile>". The first partition probably starts at an offset of 63 * 512 bytes.

sudo /sbin/losetup -fs <imagefile> -o $((63*512))

Then mount the /dev/loop# device somewhere. (The # will be 0, 1, etc.) Even if the MBR is corrupt, you can guess the offset of the next image. Look at the output of
"du --block-size=512 /dev/loop#". This will give you the size of the filesystem on the first partition. Try this as the offset plus 63 or 65 blocks to mount the second one.
sudo /sbin/losetup -fs <imagefile> -o $(((<size from du>+65)*512))

If the mbr of the image is intact then you don't need to use the results of "du" and can use the "fdisk -lu" values directly.

Otherwise, you could always go back to your backup...

Now I've written that, why does it look absurd? It really shouldn't.

Thanks for all the replies!

First, I realize that I could go in one by one, but I'm trying to find a way to do this w/o all that hassle. If there are no other options, then I suppose I will have to resort to that.

I tried mounting the ddrescued image (of the /home partition, not the entire drive), and it failed:

Code:

# mount -o loop home.img /var/recover/

mount: wrong fs type, bad option, bad superblock on /dev/loop0,

      missing codepage or helper program, or other error

      In some cases useful info is found in syslog - try

      dmesg | tail  or so

Code:

# dmesg | tail

-snip-

[53420.073341] EXT3-fs: corrupt root inode, run e2fsck

Remember that the partition was already subject to a fsck, albeit only part-way through (I canceled the fsck).

I'm wary of running fsck on the image, since that'll only bring me back to the state of the /home partition I have right now.

I'll try out some of the SourceForge tools