Tony said:
I recently reinstalled windows XP on my HD. The HD originally had two
partitions, the operating system on C:, and all of my data on D: After
reinstalling the operating system on C:, ALL of my data that was on D: is
totally gone???
What happened to my data??? Did reinstalling the operating system on the C:
partition delete everything on the D: partition???
That might depend, on how big the original C: partition is. If the
new install overwrites the area physically where D: begins, then
it could be badly messed up. Otherwise, you may be able to
regain access by
1) Slaving the drive to another computer. That means adding the
drive to another computer somehow, so you can work on it.
A USB enclosure, a USB adapter, plugging into an IDE ribbon
cable connector or using a SATA cable, may give you that access.
2) Run TestDisk, have it scan for partitions. If the start of D:
is not physically overwritten, TestDisk may be able to develop
a partition value for it (i.e. figure out where it starts). Basically,
you want to keep the D: partition info, and if need be, zero out
the entry for C:. That is in case the info is inconsistent, and
C is overlapping D. You should at least have a foggy clue as to
how big the original partitions were, in order to understand
whether what TestDisk is finding, is consistent with your
recovery efforts.
http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step
Say the original C: was 20GB and D: was 80GB. By accident, you make
one big 100GB partition from the drive. Run TestDisk. If it spots
a partition starting at the 20GB mark, then you'd be reasonably
confident about that being your D. If the size of C before it, is
20GB, then you know C is not overlapping D. You should be
able to eyeball the partition table, before writing it back.
If at any step, you don't like the direction TestDisk is taking,
you can press <control> <C> when sitting in a menu. That should
stop the program immediately. Some menus in TestDisk don't have a
Quit option, and you can use control-C as a substitute for the missing
ability to quit.
3) Once a new partition table is in place, D: may magically reappear.
In which case, you attempt to copy the data from the disk, to
somewhere safe.
4) If using TestDisk to make a new partition table, is not
resulting in any files showing up, then you might need a
scavenger. A scavenger cannot hope to do a good job, so you
could end up with thousands of nameless fragments. I haven't
used these myself, so cannot tell you what percentage of the
time they get "lost in the woods".
http://www.cgsecurity.org/wiki/PhotoRec
http://www.pricelesswarehome.org/WoundedMoon/win32/driverescue19d.html
If you're using a utility like that, you copy the recovered data to some
other disk. If you're going to do work like this, make sure you have
enough storage space *not* on the bad disk, to store the results of
the recovery. Do not write the files back onto the broken disk. You
should treat the broken disk as "read-only" as much as possible.
If you were serious about this effort, you may make a sector by sector
copy of the broken disk, before doing step (2) above. That is in case
you make a mistake along the way. If you have a sector by sector copy,
then you can restore from that, and attempt file recovery again.
A sector by sector copy is different than the copying of files
that an ordinary backup program might do. When you back up sectors,
it doesn't matter how damaged the underlying file systems are, you've
got a snapshot of the disk. So even if zero partitions are showing in
Disk Management, you can still copy the disk.
I use Linux "dd" for this, and if there are sectors in error,
the program "dd_rescue" is supposed to handle that situation (by
ignoring things it cannot read).
So that is a basic DIY approach to data recovery. Ideally, you'd
purchase two spare hard drives, as big or bigger than the broken one.
One spare drive contains your sector by sector backup (in case you
make a mistake along the way). The second spare drive, is to hold
the recovered files, whether they became accessible in step (3) or
as a result of a program in step (4).
Another convenient tool, so you can learn about partition tables a bit,
is PTEDIT32. When you're using the recovery computer to work on the
disk, you can use this to look at the boot drive on the recovery
computer.
ftp://ftp.symantec.com/public/english_us_canada/tools/pq/utilities/PTEDIT32.zip
The partition table has room for four primary partitions, and
this is what TestDisk is going to attempt to correct. (It is possible
to have more partitions than this, via extended partitions. Judging
by the interface, I don't think PTEDIT32 will be able to show that
info.) If you double click the "Type" field, it has a translation table
from the hex number, to a file system like NTFS. In this example,
the "DE" partition is a sneaky Dell partition. It is either
something for recovery, or some other kind of multimedia stuff.
I'd have to go look it up. On my current disk, I have a couple
"0C" partitions, which are FAT32. And one "07" partition, which
is NTFS. You can use a tool like this, to write down the values
from the broken disk, before you start work on it. And later,
after TestDisk is finished, you can review this again, to
see what has changed. So at least this allows you to monitor the
numbers used in the primary partition entries.
http://i24.photobucket.com/albums/c5/ghostimage/PTEditVista.jpg
HTH,
Paul
)