You haven't indicated whether the partitions are visible or not.
To gain access to the partitions again, you can use an application
like TestDisk. What it does, is re-compute what the MBR and primary
partition table should look like. A program like this should be used
with some care, because it can also find previously deleted partitions
and try and include them in the new partition table. Human judgment
must be used, before clicking any option to "Apply" a change.
(I had a disk with three partitions, where it tried to put back
a four partition table in the MBR. The fourth partition, was a
partition I'd deleted months ago. Two of the partition definitions
actually overlapped, which would have lead to a disaster if I'd
used that new MBR setup.) You can press control-C to get out of
this program, even if Quit is not an option on the screen. Test
that control-C works for you first, before going any further.
http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step
TestDisk also has a screen, where you can get it to list
the files at the top level of the disk. This lends confidence
that the file system is not damaged. It doesn't really have
any other practical usage.
*******
If the partitions are visible, but the partition is corrupted,
then you might need some sort of data recovery program. Whether
the files can be recovered, might depend on how fragmented the
files are. It could be, that files which are contiguous on disk,
are easier to recover than files which are fragmented.
Before doing anything to a damaged disk, you always make a backup
of it. In this case, you would make a sector-by-sector copy. In
practice, that means you need *two* empty disks before starting
work. The first empty disk, takes the sector-by-sector backup.
(Sector-by-sector backups are preferred, because even if the file
system is scrambled, the sector-by-sector copy carefully copies
every detail. Nothing gets lost by doing that kind of backup.)
I use this freebie, for copying one disk to another, sector by sector.
http://www.chrysocome.net/dd
The second empty disk, is the storage space for "recovered files".
If a recovery attempt that does "in-place" repairs fails (such
as running CHKDSK), then you restore from your first disk, the
one with the sector-by-sector backup on it. Always keep an
unadulterated copy of the original disk around, in case any
of the repair tools makes things worse. An example being, the
repair-in-place tool called CHKDSK.
Any tool which can use existing file system info, stands a
better chance at recovery, than a tool which "scrubs the disk
sector by sector, trying to rebuild files". When files are
contiguous and not fragmented, the scrubbing technique might
yield a good, loadable file. But using that method, you end
up with 20x as many files as you originally started with.
Which means most of the files you are evaluating, are
temporary files which have since been partially overwritten.
Normally, when you delete a file, the file system is lazy,
and doesn't rub out the old file with zeros or anything.
It means there is a large amount of "info", that a recovery
tool can find, info which is no longer relevant. A scrubber
tool, will recover both deleted and active files, and can't
tell the difference.
For example, say I use a Photo Editor. I edit my wedding
snapshot. I save intermediate copies of my edit, while
I'm working. Maybe there were ten intermediate files.
Only the last file is kept around. The others were deleted.
The file system reuses the space (eventually), but until
that happens, all those deleted files can be partially
recovered. And that's what things like a GetDataBack will
be filling the output disk with, is stuff that was
probably deleted and isn't a real file.
So all I can suggest, is use any tool which honors
the available file system metadata. Scrubbing the disk,
and ignoring all metadata, is your very last option. As
slogging through the recovered files, to find the actual
good and valid files, will take an eternity. CHKDSK is
an example of a tool which honors the metadata it finds,
at least if that metadata has some level of sanity to it.
In this example, you can see what kind of metadata the file
system has.
http://en.wikipedia.org/wiki/Ntfs#Metafiles
$MFT Master File Table
$MFTMirr Duplicate of the first vital entries of $MFT,
usually 4 entries (4 Kilobytes).
I'm guessing what that means is, there aren't two complete
copies of the MFT sitting there.
The hopeful part, when reading the following doc is, it's
highly unlikely that large parts of the disk are corrupted.
Only the last thing the file system was working on should
be corrupted. Meaning there should be a lot of info a
recovery routine can use to get the files back. If a
recovery program only uses the "scrubbing" method, of
looking for file headers sequentially, then that's doomed
to giving a poor quality output. Only a completely defragmented
disk would help there, and you're still faced with N copies
of intermediate files which are not real files.
http://www.grayscale-research.org/new/pdfs/Exploring NTFS.pdf
This program helped at least one person, get their data off an
NTFS partition. The original site is gone. This backup site is
now gone.
http://www.pricelesswarehome.org/WoundedMoon/win32/driverescue19d.html
OK, I still see a copy here. They didn't get all of them
http://web.archive.org/web/20070101070056/http://www.woundedmoon.org/win32/driverescue19d.html
driverescue19d.zip 1,007,764 bytes
MD5SUM = 63b7e1e8b1701593d5f52c7927d01558
Good luck,
Paul
