Trying to save my family photos...
 

Note, if your advice saves my photos, I will gladly make a donation to your favorite fund! Here's my problem...

I had a home server running Mandrake 10 as the OS for many years. Recently it wasn't running and it wouldn't boot. It was configured with two HDDs and both seem to be troubled (possible sabatage?). The primary drive only held the OS and the secondary drive was for file storage. The server was always on and was used to stream music to my stereo, photos to my tv, host my web site, and my email server...so it was exposed (to some degree) to the Internet. The OS is on a Western Digital Caviar 22500 (2.6 GB) and the file storage drive is a Western Digital Caviar WD400 (40GB).

FILE SERVER DRIVE (secondary drive):
Has my family photos, music. Music has been re-ripped...but we miss our photos!!!!
I put the HDD in an external drive and plugged it into my laptop running Ubuntu. This drive takes a little longer for the red light on the external case to turn blue (don't know if that means anything).
Nothing mounts, but an extra entry appears in the /proc/diskstats file. An excerpt from the /proc/diskstats file is shown below:

8 16 sdb 19 6 200 552 0 0 0 0 0 552 552

I don't know what all the numbers mean but I believe there should be a follow on line with sdb1 (as you will see further down in my OS drive troubleshooting). I believe this drive had just one partition that was vfat since I used it for file storage and sharing between my wife's Windoze laptop, my x-Windoze laptop (now Ubuntu), and the server itself (Mandrake 10). I could look at the fstab file from the server to determine the partitions, but the OS partition on the OS drive is bad too.

Running fsck and e2fschk produced the following:

root@gateway1-laptop:~# fsck /dev/sdb
fsck 1.41.3 (12-Oct-2008)
e2fsck 1.41.3 (12-Oct-2008)
fsck.ext2: Attempt to read block from filesystem resulted in short read while trying to open /dev/sdb
Could this be a zero-length partition?

root@gateway1-laptop:~# e2fsck -b 8193 /dev/sdb
e2fsck 1.41.3 (12-Oct-2008)
e2fsck: Attempt to read block from filesystem resulted in short read while trying to open /dev/sdb
Could this be a zero-length partition?

Neither of these were of any help! Is there something else someone can suggest? If I have to I will spend top dollar to send this out to a professional service but I figured I could try a few simple tests first.

OS DRIVE:
I believe Mandrake 10 used a journaling or reiser file system but don't remember. In the external case connected to my linux laptop, it mounted one partition and gave an error it couldn't mount another. The partition that mounted was my /home so I could retrieve that data. I looked in /proc and viewed the file /proc/diskstats, below is an excerpt from the file:

root@gateway1-laptop:less /proc/diskstats
...
8 16 sdb 193 1145 2823 4192 21 10 248 344 0 2116 4536
8 17 sdb1 41 420 979 1140 0 0 0 0 0 840 1140
8 18 sdb2 11 0 46 640 0 0 0 0 0 628 640
8 21 sdb5 38 404 442 728 0 0 0 0 0 500 728
8 22 sdb6 86 285 932 1300 21 10 248 344 0 1264 1644

I don't know what all the numbers are but it does jog my memory that the HDD was partitioned something like:
Partition - Small boot partition (vfat)
Partition - /
Partition - swap
Partition - home

I ran fschk on sdb2 (assuming it is the root partition):

> root@gateway1-laptop:~# fsck /dev/sdb2
> fsck 1.41.3 (12-Oct-2008)
> e2fsck 1.41.3 (12-Oct-2008)
> fsck.ext2: Attempt to read block from filesystem resulted in
> short read while trying to open /dev/sdb2
> Could this be a zero-length partition?

This didn't help me much so I tried running e2fsck:

> root@gateway1-laptop:~# e2fsck -b 8193 /dev/sdb2
> e2fsck 1.41.3 (12-Oct-2008)
> e2fsck: Invalid argument while trying to open /dev/sdb2
>
> The superblock could not be read or does not describe a correct ext2
> filesystem. If the device is valid and it really contains an ext2
> filesystem (and not swap or ufs or something else), then the
> superblock is corrupt, and you might try running e2fsck with an
> alternate superblock:
> e2fsck -b 8193 <device>

Again this doesn't mean a whole lot to me. Is there something else I can try?

All help greatly appreciated,
imazman

So, if I have this right, you have a Mandrake 10 system that no longer boots. You took one drive out of the box and put it into a USB container and tried to access it from a working linux system. Am I right so far?

What was the history of the Mandrake 10 system? Did it just fail to boot one day? Was there a gradual decline in functionality with an ultimate failure to boot? Since you say both hard drives are fubar, I suspect you had a motherboard controller failure. Sabotage is very unlikely.

The drive you have tried to access from USB...is that the system drive or the data drive?

Get yourself a Linux Live CD - your choice of distro but I recommend Mandriva One because you are familiar with the distro and it worked in your hardware. Boot the damaged system with the Mandriva One disk. When you are up in the live CD, as root issue the commands fdisk /dev/sda and fdisk /dev/sdb and paste the results here. If you are unable to get the commands to run, that is useful information to have.

If the commands don't run (can't find sda or anything like that) move the drives into another box, boot that box with the Mandriva One live CD, and try it again.

If you had a controller failure, your disk structure could be in pretty bad shape, but probably your data is recoverable. But before doing anything else, we have to figure out what happened.

Since the drive is vfat format I guess you have tried it in the USB enclosure with a Windows PC?

Assuming that fails you could try one of the Windows utilities for image recovery on the drive. I tried several of these some years ago and was impressed with ZAR:

http://www.z-a-recovery.com/digital-image-recovery.htm

It's intended for use with flash memory - via camera or USB flash card reader - but would be worth a try with attached USB disk.

Another worthwhile diagnostic (in addition to those suggested in the previous post) is to plug the USB drive into another linux box and run the 'dmesg' command. Last few lines should report the system's attempts to recognise the drive.

You should try the following two programs in order:

1) PhotoRec: http://www.cgsecurity.org/wiki/PhotoRec
This program was specifically made for exactly this task. It also has techniques that might be able to recover the ext3 partition.

2) Foremost: http://foremost.sourceforge.net/
If photorec fails or does not recover everything, try this program. It recovers files based on headers, regardless of filesystem.

Note: When using either of the above programs, do NOT save the data recovered onto the external drive that you are recovering data from. This is probably obvious, but this would overwrite data on that drive making recovery of anything useful almost impossible. So basically, do NOT write anything onto the drive you are trying to recover data from, try to keep it untouched or more damage may be done.

@maroonbaboon: This is a Linux forum, and you don't need proprietary Window$-only crapware for this.

One more piece of info that might help, can you post the output of:

I've used Photorec and found it excellent, but extremely slow on a large disk, perhaps because it searched for multiple patterns, rather than just images.

I assume the OP just wants the pictures back from his VFAT partition, rather than an OS flame war.

Only if you don't specify any extensions.

Always try testdisk first.

I was assuming the OP wants pictures back from their ext3 partition. They were trying to run 'e2fsck' on it, so it must be ext3 or ext2. That program you posted is not only Window$-only but also only supports VFAT partitions. Very limited, IMO. I have no intention of starting a flame war, just making an observation.

JimI8,
=========
Thanks for your help and suggestions.
Yes, it sounds like you understand what I did so far, albeit I pulled both HDDs out and tried the same tests on each of the HDDs. I noted the results and info for each drive in my original post under sections called FILE SERVER DRIVE (data drive), and the other as OS DRIVE (system drive).

The Mandrake system wasn't really monitored, I turn it on and leave it be. Just used it as a central "always on" place to save files my wife and I want to share, to host my web site (i.e. Gallery2), and run my email server. If we lose power (happens often out in the woods) I would have to turn it back on...and that's how I found the problem. So I would have to say I didn't notice any degredations. I have been using this machine as an "always on" server to host photos since around 2001.

I have several CD booting distros (Mandrake Live, Centos OS, Knoppix, Ubuntu, etc.) so I will try your suggestion. I will post my results.

MaroonBaboon,
==============
Thanks for your help and suggestions too.
I did try the drive on a M$ Windoze box but I saw nothing. I also tried a couple free/demo disk restore/repair programs with no success. If I recall from just before holidays, they did not recognize the external USB drive at all. There are SO MANY disk restore/repair programs out there I can't see paying for one and it can't tell me anything, paying for another and it can't tell me anything, etc. If it's free or limited featured, I will try it and it is successful, I will buy it!

I ran dmesg and it does recognize the drive (to some degree). There are lots of valuable pieces of info in this log. It generated LOTS of messages so I will attach a txt doc which has the lines from plugging in the usb drive for the data disk. I'm not sure how to use this info yet but I will research into some things. Here are a few lines of interest (ellipsis means I skipped some lines):
> ...
> [22644.317509] scsi 16:0:0:0: Direct-Access WDC WD40 0BB-00CLB0 0000 PQ: 0 ANSI: 0
> [22644.334456] sd 16:0:0:0: [sdb] Very big device. Trying to use READ CAPACITY(16).
> [22644.338467] sd 16:0:0:0: [sdb] READ CAPACITY(16) failed
> [22644.338482] sd 16:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
> [22644.338495] sd 16:0:0:0: [sdb] Use 0xffffffff as device size
> [22644.338506] sd 16:0:0:0: [sdb] 4294967296 512-byte hardware sectors (2199023 MB)
> ...
> [22644.423321] sd 16:0:0:0: [sdb] Add. Sense: Address mark not found for id field
> [22644.423329] end_request: I/O error, dev sdb, sector 0
> [22644.423336] __ratelimit: 15 callbacks suppressed
> [22644.423340] Buffer I/O error on device sdb, logical block 0
> [22644.461160] sd 16:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
> [22644.461174] sd 16:0:0:0: [sdb] Sense Key : Medium Error [current]
> ...
> [22644.799424] end_request: I/O error, dev sdb, sector 0
> [22644.799454] unable to read partition table
> [22644.799685] sd 16:0:0:0: [sdb] Attached SCSI disk
> ...

It looks like it identified the make and model of drive, but it has the size of the drive wrong because the sixth line above has the byte size of the drive wrong (i.e. it says 2199023 MB but its a 40 GB = 40000MB drive). Also it can't find a partition table. I need additional direction but in the mean time will also try ZAR.

H TexMex H,
============
Thanks for your help and suggestions too. For now I really just want to save my photos.
The command fdisk -l /dev/sdb produced:
> Cannot open /dev/sdb
However, I looked at /dev/partitions and when I turn on the USB drive with the dataDisk the last line is added. Here is it's contents:
> cmoyer@gateway1-laptop:~$ less /proc/partitions
> major minor #blocks name
>
> 8 0 58605120 sda
> 8 1 57103011 sda1
> 8 2 1 sda2
> 8 5 1502046 sda5
> 8 16 2147483648 sdb
INTERESTING note, the number of blocks shown in /dev/partitions is half of the number listed in the dmesg command (e.g. 4294967296 512-byte hardware sectors (2199023 MB)). Mind you I know the dmesg info is incorrect because its a 40 GB drive. Not sure what this means, additional direction needed. Meanwhile, I will your other suggestions.

Thanks for everyones help. I'll post results of additional attempts.
imazman

It may be that the partitions have been damaged or destroyed, so use Photorec first, then foremost.

I tried some of the "quick and easy" suggestions first such as:
-- testdisk
-- ZAR
-- photorec
-- fdisk

testdisk, photrec, and fdisk yell that it can't open file or device
ZAR says it is of capacity 0 so it can't do anything else (also tried switching mode)

Those messages do not make much sense to me. Testdisk works on the level of drives, not devices or partitions. Did you run them as root? If so, then your drive may have sneaked into the other world. It might be time to check whether WD has any recovery software. Then again, that would not explain why your system drive seems to being having issues, too.

Btw, if the partition spanned the whole drive, you could simply repartition it without relying on testdisk (but do not format!).

Don't play with the partition table or anything else until you have successfully identified just WHAT the problem is. If you mess with it randomly you are likely to compound the damage.

Get the output from fdisk, running as root, as a starting point.

Always figure out what the problem is first!!!

I'm not going to shout through the crowd here. Some of the advice you are being given has the potential to greatly increase the damage to your drive if you follow it blindly. You need to establish what the problem is before you go off willy-nilly trying things to fix it.

If you want my assistance, email me.

Hmm, testdisk runs a diagnostic on the drive and that is going to compound the damage...
It seems to me that testdisk -in this case - is a good way of figuring out what the problem is.