Good day to all

My home web server running Ubuntu Dapper 6.06 LTS failed to come up again after a shutdown, power off and restart. The shutdown -h command was issued as normal and about ten minutes later I switched the machine off. It isn't my habit to have a monitor attached and this procedure has always been adequate in the past.

Ha - not any longer! The computer refused to boot - no operating system was found. The disk spins up fine and is detected in the BIOS correctly - fortunately I was wise enough not to try and modify the sick disk. I used a handy Kubuntu live CD to verify that the disk was not mountable.

The story so far..

I took an old Ubuntu Hoary 40GB disk (5.04 I think), installed it as primary master (HDA), installed the sick 40GB disk as primary slave (HDB) and a blank 160GB disk as secondary master (HDC).

The sick disk still wouldn't mount so I did some reading around for my initiation into data recovery! I hoped there was a utility to recover to HDC and dd_rescue seemed like a good way to start so I could try and fix it without harming the original.

I encountered the bad superblock error while fsck'ing the copied image but located a working backup superblock using mke2fs -n which allowed fsck to complete albeit still with errors. This allowed me to mount HDC. However all that was there was a lost+found directory with hundreds of entries (coloured as files, directories, devices, symlinks - all the colours you'd expect to find on a working disk's ls results) but without proper names, just numerical names e.g #4771633 - however details like groups, owners and modes where recognisable.

I also ran find (without any parameters) which returned some recognisable file names within the lost+found directory but nothing I wanted saving!

The current problem..

Hopefully you're still with me! This is all a bit new to me - if possible, what I'd like is someone with more experience (not difficult!) to walk through another attempt with me.
I have a fresh dump of the sick HDB cloned onto HDC using dd_rescue - what next?

What kind of files do you want to recover? Here's my process for general purpose recovery:

1) make an image with dd_rescue
2) run testdisk on the image
3) run foremost on the image
4) run photorec on the image

Photorec and Testdisk are both by the same author. Foremost is a data recovery tool developed by the US Airforce (I think). Typically I'm just recovering jpegs, movies, documents, etc.

Did you use dd_recover on each partition or the entire drive?
If it is on the partition, you could use one of the spare master blocks to try to mount it.
This depends on the filesystem. There may be an "sb=" option to use a different superblock to try to mount the partition. There may also be an "errors=remount-ro" mount option (ext2/3, reiserfs). Together you may be able to mount the filesystem or it's image and then recover files from it.

Thanks for your replies - I only need to recover text files: html from my /var/www and /usr/local/apache2/cgi-bin folders.
I would also like to recover the images from those folders but it's not essential.

Regarding dd_rescue (I assume you're talking about dd_rescue!) - I only used it on the entire drive. I'm not experienced with this at all, I'm afraid I don't know how to use it in a more refined way! Any hints gratefully received!

What fs do you have? If it is ext2/ext3, what's the output of mke2fs -n. Try to run with mke2fs -n -b blocksize (usually it is 8193). When you get the location of the correct superblock, run e2fsck -b with this location.


Check this too: http://man.he.net/man8/debugfs Maybe you could fix inodes with this.

Thanks for the suggestion - I think this is the procedure I followed before but the results were not very helpful. I did find a good backup superblock using mkefs -n and then ran e2fsck -b xxxxxxx (whatever the block number was!) but it came up with that huge file of numbered files I mentioned earlier!

Woah - testdisk has just given me a big chunk of hope back! It appears to find my good, old file structure! I've just navigated all over what looks like my old disk!

I'm running out of time at the moment so I'll have to try foremost and photorec later on - my sincere thanks for everyone's help so far.

It may be easier if you had used /dev/hdb1 and /dev/hdb2, etc. instead of the entire disk image, /dev/hdb. You can try to mount an image of a partition because it contains a filesystem. The disk image contains several partitions so it can be harder to work with. Also, it's possible that the filesystem on one of the partitions wasn't damaged if the damage was with the mbr.

However, if the mbr was damaged, there may not have been devices for each partition.

If this turns out to be very complicated I'll probably try and make a fresh image of just the relevant partition.

Been playing with testdisk again - love that app! I'm hoping that using testdisk to re-write the partitions (onto /dev/hdc, that is) will be successful.

I am now perfectly willing to have children with testdisk!
Success - looks like the damage wasn't bad, the partition table was screwed up but testdisk rewrote it, rebooted and - woosh - a bunch of partitions appeared on hdc!
Copied stuff to another computer and I'm now planning on how to set it up on a proper hosted service!

My sincere thanks to all who were good enough to help me out.