Aaron, Thanks for the lengthy reply. Unfortunately this is a Windows box (I probably didn't mention that), with an NTFS partition. I'm the Linux geek in the family - the wife is still on Windows. I'm sure the below information is a great reference for anyone who comes across it in the future though.
Owen On Sun, Aug 28, 2005 at 05:36:58PM -0700, Aaron S. Joyner wrote: > Owen Berry wrote: > > >On Sun, Aug 28, 2005 at 02:43:40PM -0400, Wing D Lizard wrote: > > > > > >>TrackZeroNotFound sounds bad. > >> > >>Can you read the partition table with fdisk? If you can't ( and > >>can't fix it), then you won't be able look it as a filesystem. > >>Maybe there are utilities that can look at the rest of the disk > >>as a raw device, but I remember reading that if the first track > >>went bad then the disk was gone. > >> > >> > > > >Nope, fdisk doesn't work. > > > > > All hope is not lost because of this, read on. > > > > > > >>The partition table must go in the first track, if it's bad then > >>your out of luck. The best chance is to find some way to read the > >>raw data off of it and try to deduce the partitions, then the > >>filesystems, then the files... > >> > >> > Actually, with ext2 (and ext3) the partition information is stored in > the super block (the first 32bytes of the partition) and then replicated > numerous times across the drives, as backup copies of the super block. > The reason for this, is of course, loosing the super block is disastrous > to being able to recover your data. You can try repairing the data > (don't do this yet, read all the way through first) with an alternate > super block elsewhere on the partition. The location of the alternate > super blocks varies based on the block size of the partition, check `man > e2fsck` for more info. But, running e2fsck is usually with the > intention of trying to repair the filesystem. Doing this on a "dying" > drive is only going to stress it, likely aggravating the problem and > resulting in effective meltdown. Step 1 should be get as much of the > data *off* the drive into a copy, then see what you can recover / > restore from the copy. This is usually done with dd, something along > the lines of: > dd if=/dev/hda1 of=/backup/hda1.img > > If you encounter read errors, you can stop the command and restart it > beyond the unreadable section with the seek= and skip= arguments, check > out `man dd` for more details. Use great caution, and if it comes to > this, feel free to drop me a line or enlist someone local who's done > this with dd for help. > > Once you have the partition copied off to an image file (likely missing > a few sections, at least) then you can go about attempting to restore > data from that image file. Step 1, make a copy of the image file and > leave it alone. If you screw up your working copy, you don't want to > have to go back to the original media to pull another one. :) Step 2, > try and recover the filesystem to a mostly-working state with e2fsck > against the image. You can use the -b and -p switches in this endeavor > with potentially complete success (depending on how much of the img was > missing, and how critical those portions were). If recovering the > filesystem information with e2fsck fails, you can then dig a little > deeper. Grab a copy of foremost (a forensic data recovery tool), and > you can begin to look for specific important files individually. > Foremost works by scaning the actual bits on the disk, and looking for > the bits that are always found at the beginning of certain types of > files, and then reading that section of data up until it finds the bits > that signify the end of that type of file. It won't know the name of > this file, only it's file type and contents. There are common > signatures included with foremost for things such as jpegs, gifs (and > most other image types), word docs, excel docs, etc, etc ad nauseum. > Your ability to recover data in this manner is limited only by your > patience, knowledge of what file types you're looking for, and what bits > were actually copied off of the drive successfully. > > >This is probably what the professionals do for the big bucks. > > > Actually, what the professionals are doing for the big bucks is *highly* > more complicated. Depending on the severity of the problem, they're > either replacing the electronics as previously described, or more likely > taking the platters out of the drive in a clean-room environment, and > putting them into either a very similar hard drive, or a special machine > designed to take all manner of platters, which has special heads and > logic boards capable of reading just about what ever is on the drive. > Either way, once that swap is complete, they fire up the drive, and copy > off what ever bits they can to an image file. Then they proceed much as > described above. > > > -- > TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug > TriLUG Organizational FAQ : http://trilug.org/faq/ > TriLUG Member Services FAQ : http://members.trilug.org/services_faq/ > TriLUG PGP Keyring : http://trilug.org/~chrish/trilug.asc > -- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/ TriLUG PGP Keyring : http://trilug.org/~chrish/trilug.asc
