The suspect was immediately either the IDE controller or both of its drive. After transplanting the drives to a seperate machine and failing to find their partitions, and after trying a new drive in the machine it was looking as though possibly all were fried.

A couple months have passed and my landlord has had me build him a new computer and the day has come to try to recover his data... Below is the process I've used to diagnose and recover his files.

1) Attempt to image the entirety of the drive

With the physical stability of the drives in question, the first order of business was to mitigate the amount of work done against the failed drives themselves. Windows claimed the drives were unformatted, and linux would not let me mount them (although their partition tables were visible).

The weapon of choice was dd, a data-copy utility that works at a low level and with a little bit of knowledge can be an invaluable tool. dd can be extremely dangerous if you aren't careful with it!!! dd is basically a data-copy tool which takes a couple arguments; "if" (input file) and "of" (output file). The device/file you set "if" to will be copied to the "of" device/file. You can add more parameters to control the amount of data copied, and the blocksize that the harddrive's partition uses.

Example: Backing up a drive's partition table

The drive partition table is stored in the first kilobyte (not certain this is always true, it may depend on the block size) of the partition. To make a backup:

dd if=/dev/[drive] of=$HOME/[drive]_part.bak bs=1k count=1

This will copy the first kilobyte (bs=1k count=1) from /dev/[drive] to a file called [drive]_part.img in the executing user's home directory.

Back to data recovery with dd... to make an image of the entire drive I used the following command, note that this creates a file equal to the physical size of the disk, so be sure you have enough room. i.e. if you have a 1GB partition on a 100GB drive (and 99GB unpartitioned) the resulting image will be 100GB.

dd if=/dev/[drive] of=$HOME/backups/[drive].dmg bs=512 (NOTE: bs varies depending on the filesystem settings, common sizes are 512, 1024, and 4096, although many others are possible. One way to determine the block size is to try copying one 512b block, one 1k block, and one 4k block (so on so forth). Wrong block sizes should result in an error, ruling out the selection.

dd does not work through errors by default, so if it finds bad sectors or other obstacles it will error out--providing evidence of the type of failure on your hands. I lucked out, and dd ran through the full 20GB drive without error which told me that the drive failure was likely with the partition or filesystem and not a hardware failure. If dd fails due to drive errors such as bad sectors you can use ddrescue or gddrescue, both of which use dd and will replace errors with null (nothing) values in the image, resulting in a backup image of as much data as possible. One other very cool feature is if you use these tools to copy from a device that is inconsistently reading it's contents then you can run the tool multiple times, and if a 2nd (or 3rd, 4th...) pass is able to successfully read what a previous pass failed at it will fill in the void left by the earlier passes due to the error. This proves wonderfully useful on scratched CDs, among other things.

Now for the real fun: With the disk image in place I shutdown and remove the physical drive from the machine (so that if it is a hardware issue, any further damage will be prevented. My landlord was considering having the drive professionally recovered if we were unsuccessful, so we wanted to make sure we did no further harm to it). Upon booting back up I set the drive image to a loopback device, which lets you mount a disk image like it were a regular drive (iso's work great with this)

2) Attempt to mount the image

After unplugging and removing the dead drive I tried to mount the image I'd just made:

mount /home/steve/[drive].dmg -o loop -t vfat /mnt/recovery

But it failed, barking about a bad superblock. This was starting to look more like a bad partition table than a fried drive--so back in went the drive.

3) A great utility

After some Googling I found multiple references to a utility called testdisk which is a free drive recovery tool. My only beef was that it only seems to work on physical drives, not loopback images (like what I made above). So with the drive back in I ran testdisk, and after selecting the appropriate drive and type from it's menus it immediately told me I had a bad partition table.

Using the restore and scan options of testdisk brought the drive totally back to life! I was very impressed by it, as it seems to have a lot of power under the hood but not a lot of difficulty in it's user-interface.

The drive lived! I saved it's updated partition tables back to the drive, rebooted as it recommened and was able to successfully mount the partition.

4) Get everything off the drive

There was no sense running the risk of letting the drive cause more problems, especially as there was over a Terabyte of free space on the new machine. So I rsync'd everything off of it immediately:

rsync -av /mnt/[mountpoint] /var/storage/recovered/

5) Shred the drive

The old 20GB drive was recovered, and my landlord wanted to recycle it (give it away). So first we wanted to shred any remnants of it's contents. There is a GNU utility aptly named "shred" that does specifically this.

shred /dev/[drive]

And many hours later (shred defaults to 25 passes, which is extreme but can be changed) the drive was wiped clean.

The UUIDs of my new installation were lost, so after a little Googling I found that there's a helpful little utility called "vol_id" specifically for determining this type of info...

vol_id [partition]

and voila, I've got my fstab back in fine shape

Doing a 'cat /proc/mdstat' produced:
Personalities : [raid6] [raid5] [raid4]
<none>

Thankfully I had backups of my mdadm.conf and lvm.conf files so I knew that as long as I didn't alter the data on the drives I could always fall back to Edgy and still have my files.

After trying a few things with mdadm, all unsuccessfully, I decided to uninstall it entirely. So I made a (second) backup of my mdadm.conf and lvm.conf files, and did a:
apt-get --purge remove mdadm lvm2

This uninstalls the packages and also removes the config files (that's what the --purge option is there for).

After uninstalling them I verified the configs were gone and reinstalled the packages through Synaptic inside of GNOME. During the install it prompted which arrays were required to boot. On my failed upgrade I had configured it with "all" but I really didn't need my array at boot time, my root partition is on a standalone IDE drive, so this time I told it "none".

I expected to have more tinkering to do, but after the install I again did a "cat /proc/mdstat" and to my surprise my array was back! *yay*

Now I just had to get my lvm partitions back. I've found the Gentoo LVM2 installation guide very usefull, and a good resource for LVM, so I turned to it to see how to recover volumes. The commands to restore my volumes were:
vgscan
vgchange -a y

And voila, my array and it's partitions were good as new. A quick "mount -a" brought them all up without a glitch!

The process is easy-as-pie. Just run "update-manager -c -d" and it's a simple walk-through process.

Obligatory Warning: Feisty won't be officially released until April, and it's still labeled an Alpha release, so be warned it has lots of bugs and is not stable--personally I see my gnome-panel crash quite often, as well as a number of other oddities. You've been warned