[TriLUG] Hard drive recovery

[Owen Berry]

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
>