Hi all,

I have a failing Hitachi 250GB Sata hard drive from my Dell laptop (Vista 64bit OS). I believe it is a hardware problem, not just logical, from the clicking noises certain sections of the disk make. I've already put the hard drive in an external enclosure and have been using a variety of Linux rescue CDs to see the partitions, etc. (since Windows can't see the drive and hangs when trying). I am a noob at Linux however...and at hard drive stuff too. I am keeping the drive on ice packs to avoid overheating and additional damage.

I've been running Photorec and managed to recover a whole variety of files, except of course the two Open Office (.odt) files I most desperately want. The Photorec log shows input/output errors as it tries to read sectors. I know there are a whole variety of bad sectors and the drive seems to physically have more difficulty at the beginning of the NTFS partition with all the data. I have done basic analysis with Testdisk as well but didn't want to try file system repair before getting everything I could off the disk.

So here are my questions (please pardon errors in terminology - I'm still learning):
1. Will other approaches besides Photorec be likely to recover more or different data? Things like Testdisk or ...? Would repairing the filesystem (if possible) make fragmented data more likely retrievable since the size/location of files might be recovered?

2. Would it be worth using ddrescue (Diaz' version) to either image or clone my drive before playing around with filesystems? And is an image or file-type copy better?

3. If ddrescue is worth trying, how do I set up my external target drive? I have a WD external HD that is the same size as my failing laptop drive. I recently wrote zeros to it to erase all data however, so it has no partition table. To do either the image or the file copy, how should I reformat/partition my WD HD (fat32? NTFS? multiple partitions or one big one?)? And if I only image the main NTFS partition of the failing drive, will I still be able to use tools like Testdisk on the image?

4. Is data that you use frequently more likely to be at the beginning of the partition? I don't quite get how data is stored on a hard drive. My drive was pretty new so I'd only used a small portion of the 250GB. Can I focus on the first part of the partition with Photorec, etc. or do I need to run it through the entire drive?

I've posted this on a forum for one of the rescue live CDs too, but that forum doesn't seem to get much traffic so thought I'd try here too...

Thanks so much for your time!
Jen

Let's focus on what's important. You have a hardware problem. The first thing you must do is to perform a bit-by-bit copy of the disk to a file on a mounted partition on a physically different disk.
- Attach your external harddisk, create one partition and mark it "83" (Linux ext).
- Format the partition with ext2fs, not ext3 as you don't need journalling (and you don't want NTFS unless you must use wndws recovery tools).
- OK. You want to run dd_rescue, so boot the HELIX or KNOPPIX Live CD. Suppose your "victim" drive is /dev/sda and your external drive is /dev/sdb. - Mount the external drives partition. If it doesn't automount 'mkdir /mnt/recovery; mount /dev/sdLETTER1 /mnt/recovery' (take the LETTER from watching dmesg input as you plug the drive in or run 'fdisk -l'). Once mounted at /mnt/recovery (you don't need to mount the "victim" drive) run dd_recue like this: 'dd_rescue -l ./dd_rescue.log -o ./dd_rescue.bad -f -v /dev/sda /mnt/recovery/sda.dd 2>&1 | tee ./dd_rescue.tee'. What this does is copy the whole of /dev/sda to a file "/mnt/recovery/sda.dd" that will be readable by all applications that can read 'dd' images (photorec, testdisk, foremost, scalpel, pyFLAG and such). Once the process ends copy the files ./dd_rescue.log, ./dd_rescue.bad and ./dd_rescue.tee to /mnt/recovery/ (or another removable medium) before umounting all mountpoints and rebooting.

Only then would it be safe and the right time to ask about recovery of individual files.

First off, you should definitely make an image of the drive with dd_rescue and then run all recovery efforts on that image. Since it is a hardware failure, every time you spin the disk up it's possible you are damaging more of the disk. So take an image first. Since you only care about the data files, you just need the main NTFS partition (assuming that's where your data is). The other partitions from a factory install are probably diagnostics and/or reimaging tools.

After that, you can try using testdisk on the file to repair the partition table if it's damaged. I think there's a tool under development called ntfsck, but I don't think it's working yet.

If you still can't mount the partition after that, you can run photorec (which you already did) or try using foremost. You may actually have recovered the odt file (though it might have a different ending). Try grepping through the files you recovered for a phrase you know is in each document (like the title).

Thank you both so much for your responses!

Okay, I'm setting up the image process.

Will it matter if I'm imaging a NTFS Partition (the laptop was windows Vista) to an ext2 formatted external drive?

You both mention dd_rescue. I've read that ddrescue is more powerful, although I don't quite understand all the things it talks about. Here's the wiki I was referred to: http://www.forensicswiki.org/wiki/Ddrescue

Does one work better then the other? Since it will probably take a day or two to image everything (given how slow everything else has been going), I would hate to start the "wrong" one...

pljvaldez, you mentioned grep - wow! cool command! I found some references to the two files I'm trying to retrieve in files I recovered with Photorec. It mentions a couple binary .gif files too. How can a text document show up as a .gif with Photorec? How on earth would I check the data as text? I obviously don't care about formatting or anything...just want the text content of my two files.

Thanks again...
Jen

No, 'dd' and equivalent tools just copy data. They do not interpret what they are copying as RAW, ext4 or FAT16. It also does not matter in relation to the filesystem type of the partition you are copying the image file to except for system constraints like the maximum size a file can be.


I mentioned dd_rescue because I have used it. I prefer it because it can read from back to front as well which may come in handy when your drive is utterly b0rken. If you think ddrescue fits your purpose better then by all means use it.

You can just open a text editor (like Kate or Gedit) and then open the *.gif file and see what happens. Or even try using OpenOffice Writer. At worst it'll look like a bunch of gibberish. At best, your text will be there (maybe with some other unrecognizable characters in between).

Anyway, photorec works by looking at the headers and footers of common file types. They usually have a very distinct pattern that allows photorec to know what type of file it is and what the end point should look like. But occasionally something might be messed up (like one of the bad sectors of the disk may have cut out part of the header), so it might have mis-identified the file as a *.gif even though it's really some sort of text document.

Waaahhooo!! I used ddrescue and have found a bunch of my files using Photorec on the image. Is there a way to mount an image so I could use Testdisk on it or something and maybe get back the original file names? Does the image have to be mounted to use Testdisk? The image is only of the main NTFS partition of the original drive and was the OS boot partition...

Sure. Just do testdisk imagename.