Hard Drive Data Recovery
"Help! My BIOS sees my hard
drive, the motor spins - but the system won't boot, there's no C: drive and FDisk shows no
partitions!!"
Drive must be detected by BIOS, spin, seek, and
not be totally overwritten.
If so, it's "mission usually possible". A quick and FWIW overview...
First thing to do is exclude a CIH virus payload,
because there's an excellent CIH recovery tool available for free from http://www.grc.com; it's a very cautious tool, and won't
operate on a drive unless it recognizes the situation as pure, unmodifies CIH damage. So
you don't want to make any changes first!
If CHS 0,0,1 is physically dead, you have your
work cut out for you. Otherwise, it's not too bad... generally, the procedure I adopt is
as follows (using Norton DiskEdit - the sole reason I bought Norton Utilities, the CD's
still in shrinkwrap):
- Search for subdirs (detected as objects, or look
for the characteristic . and .. entries that start every subdir) and ballpoint the cluster
addresses of the . and .. addresses for these. The . points to the cluster it thinks it is
on, and the .. points to where it came from - if you have to rebuild a root, you only need
the ones where .. = 0, as those are off root and will tree the rest. When you ballpoint
them, record the physical sector address that they are found at, as that is independent of
the file system parameters (which are unknown or uncertain) and are less granular
(multiple sectors per cluster, so you need sector-resolution addressing)
- Asses the list of subdirs. Do they form an ordered
sequence from low . cluster address to highest? Or are there parallel tracks, suggesting
perhaps a FAT16 and FAT32 volume
that occupied the same physical disk space at different times? Or do they start again from
a low number after a while, suggesting the start of a different volume
and thus a HD with an extended partition, or multiple primaries?
- Virtualize the file system. By this, DiskEdit uses
"on the fly" parameters and views the HD as if these were in effect, allowing
you to write files off to another HD. Before you do that, you have to...
- Assess the sanity of your virtualization. Look at
two successive "found" subdirs; does . list the same cluster address that the
subdir is actually on? If so, does accessing the same subdir via the physical sector
address pull up the same as accessing it via the . cluster address - or is there a sector
offset within the cluster? Do all of your set (or sequence subset) of subdirs line up the
virtualized "you are here" cluster address with the . address?
- Once all is well at (4) then you can fulfil the
prophecy by splatting in that info as appropriate (hand-rolled, if necessary) CHS 0,0,1
(MBR, partition table) and (usually) CHS 0,1,1 (partition boot record). Back up the raw
sectors concerned, and see if you have a sane-looking file system outside DiskEdit. If
so...
- Do not write to the file system!
Yes, that means you cannot do this recovery data pull in WinME, which drools a _Restore
folder onto every HD volume it sees. Instead, copy off everything to another
physical HD - after that, repeat (1-6) until all volumes have been recovered (if in doubt,
treat parallel file systems - e.g. a FAT32 over a
FAT16 - as two separate volumes, even if you know that one will have garbaged much of the
other)
- Re-FDisk and re-Format the volume, and copy everything
back. That's the only way to be assured of a write-sane file system that won't bite your
butt down the line. Flood-test the volumes first, if you have doubts about volume overlap
or wraparound issues.
A common error is to use FDisk at (5), i.e. by
recreating a new partition that lines up with what you are about to recover. There are two
things wrong with that:
- FDisk does "probe writes" into the
partition it creates, destroying arbitrary chunks of FAT, root, etc. Ugly stuff.
- Existing file system will be invalidated by FDisk,
i.e. drive letter will show after reboot but accessing it will generate "Invalid
media" error as media descriptor is no longer sane.
If you compound the error by doing a Format (so
as to create a sane media descriptor byte), you blast away the existing FAT as well as
blotting out the root. The root is a small deal - from the above, you can guess how to
recreate a scratch root that will point to all the recovered directory subtrees - but the
loss of the FAT will invalidate any fragmented files longer than a single cluster, because
you will be forced to use an assumed flat-FAT to pull the data.
Note that a flat-FAT file system is not
write-sane, and many utils that attempt to browse the file system may die a grizzly death
as in effect, the entire volume is one huge crosslinked file chain :-)
I didn't say it was easy, though once you've done
it a few times, it's not such a big sweat. But impossible it is not - unless the poor
thing had disk compression in effect, then most (if not all) bets are off.
Techs will rise to this challenge in one of four
ways; try it and botch it, try it and succeed, tell you it can't be done, or tell you it
can be done but they don't/won't do it. Of these four responses, only the second and
fourth are acceptable (the fourth is fine; data recovery is time-consuming and not a
universally-held skill). The third is deeply unacceptable if they have already proceeded
to screw things up massively by "just re-installing Windows".
Note: This page is very likely to evolve in the
next few weeks (software-speak that means "months"), into something a lot more
useful, if still not exactly novice-friendly.
(C) Chris Quirke, all rights reserved
Back to index