Re: Hard disk data recovery.

b173@xxxxxxxxxxx wrote:
Grant wrote:

[forgive the snip]

The Windows 2000 machine says that the drive is there, but it isn't
formatted. Now there's a lot of important stuff on that drive that
needs to be salvaged. I've tried rolling back the registry etc... blah.

You're screwed? Why? You did not immediately remove the drive from
Win2k access. Win2k silently does things to visible hard drives, not
the best way to attempt data recovery (or the original transfer).

So now I want a real solution.
To what? Just start over and do it properly.

The solution that I wanted was to recover the data that is on the (now)
unformatted disk. As far as "doing it properly" goes... I think I just
learned that lesson :)

First thing is to decide _what_ caused the failure as best you can. I
would be concerned that the hard disk you were writing to encountered a
hardware/firmware problem.

the disk but it doesn't know what filesystem type it is. I think it
might be FAT32 but it could be NTFS.

Being so vague, how can you expect any data transfer to not also
be vague --> inaccurate, non-trustworthy, a total waste of time.

didn't mean to be vague, I just didn't know. The fdisk output says
FAT32, I'm inclined to believe it.


Any suggestions? I really want to recover this data, it would be great
if linux could be my hero :)

Just how important? How many hours of your time are you willing to
invest? How much $ are you willing to pay for a specialist recovery
shop to recover what they can?

Boot some linux rescue CD, and tell us what is output from
# fdisk -l

Here's the output:

Disk /dev/hdb: 160.0GB 160041885696 bytes
255 heads, 63 sectors/tracks, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks ID System
/dev/hdb1 1 19457 156288521 5 Extended
/dev/hdb5 1 19457 156288521 c w95 FAT32 (LBA)



Then detail the source and target partitions that you are copying.
Mount any partition you want to recover as read-only (man mount),
linux is able to read NTFS and FAT32 without a problem. You need
spare partition space writable by linux to store an image of the
partition needing recovery. From then on you work with the image
file.

Let's see if I have this right. You are saying that I should be able to
mount hdb5 as read only, save the contents as an ISO (to another drive)
and then go from there? I just want to confirm all this before doing
further damage.

Grant is suggesting that you _should_ get that hard drive out of
service ASAP! The "image" he is talking about is just a raw
"bit-4-bit" copy of the partition of the failed disk, similar to what
you would get with Norton Ghost imaging software. Linux rescue CDs
ususally include something that will allow/help you make this copy.
Eg.,

http://www.sysresccd.org/ << no personal experience, luckily
Ask around here for experienced suggestions.

Howerver, before doing even this minimal step, I would test the low
level integrity of that hard disk. Many makers provide disk utils that
will provide this low level access and _may_ allow you to recover or
repair _some_ problems. What kind of HD is it? Go here to find what
tools may be available:

http://www.duxcw.com/faq/hd/diag.htm << find one that operates from a
DOS boot disk
http://smartmontools.sourceforge.net/

This last one can provide more background than you will hopefully need
as well as tools related to S.M.A.R.T capable hard drives.

If you confirm that there are no hardware related problems (including
simple things like ribbon cables), then you can assume that the problem
is a corrupted file system. Now you should make an image of the
boinked partition and do all other work on _that_ image rather than the
troubled HD/partition. Remove that original HD from the box and set it
aside. It is your _only_ source/backup of the lost data. Maybe a good
idea to make two images of the HD partition.

Question then is to determine just what the problem is. fdisk output
seems to indicate that the "partition table" is OK. However, Windows
uses an extended partition in a peculiar and difficult to recover
fashion -- unlike Linux. So I would try to determine the
integrity/correctness of the partition table first. This can be
tricky, tedious, and scary if you make a mistake with a disk editor.
Go here for the best info I've found regarding the details of MS
partition and file system usage/layout. There is also a free, but
dangerous, disk editor availabe. For a disk editor you might try a
free trail version of a commercial product or find a friend with Norton
Tools or something similar.

http://thestarman.dan123.com/
http://thestarman.dan123.com/tool/FreeTools.html
[ look for PTS Disk Editor ]
http://thestarman.pcministry.com/

Don't be put off by the "extra" stuff.

This might be useful to check out as well for some tools:
http://www.partitionsupport.com/utilities.htm

If that checks out, then we can figure on a _completely_ boinked file
system. Ie., is so corrupted that it cannnot be recognized as being
formatted. Do not jump to this conclusion too quickly; check the
partition tables first as best you can. Do not run any automated file
system repair utils. FAT32 FSes are easier to work with and might be
recoverable. NTFS, otoh, is beyond my experience regarding recovery.

Do you know which files are "lost"? Presuambly, the failure retained
the untransferred files intact. What other files pre-existed on the
disk? Backups? Did you defragment the partition before starting this
transfer operation? If not, disentangling the file fragments is likely
beyond the skills of "ordinary folks" (ie., you'll have to use a data
recovery service to _try_ to recover the data).

You can try looking at the partition with a disk editor, but usually
I've had little to no luck recovering much data that way. You can get
an idea just how badly things are boinked -- like large zeroed areas --
but piecing together the right blocks to reconstruct a file are, ummm,
tough.

At this point you give the recovery job to someone else or use a
commercial software recovery app and hope for the best (either way).

good luck,
prg

.

Relevant Pages

  • Re: Dual Boot Instructions
    ... the PHYSICAL DISK number, ... Partition and Boot Volume as well as other things. ... You should, at any one time, see ONE System Partition and ONE Boot Volume - ... for the typical two floppy drives and assigning Drive C: ...
    (microsoft.public.windows.vista.hardware_devices)
  • Re: Boot Problem
    ... Right mouse click the dest disk> Advanced> Edit ... but it should eventually boot to Windows. ... I see a lot of posts in here about the ability of Acronis to clone drives. ... I have managed to successfully copy by DELETING partition, ...
    (microsoft.public.windowsxp.hardware)
  • Re: Dual Boot Instructions
    ... OS on a separate partition. ... the PHYSICAL DISK number, ... You should, at any one time, see ONE System Partition and ONE Boot ... The name stuck when we added hard disk drives, ...
    (microsoft.public.windows.vista.hardware_devices)
  • Re: A Dual-boot question; I thought C was always the partition with the running OS
    ... The Server 2003 will then call its partion "C:" Local Disk. ... When Server 2003 starts up, it will call itself "C:" and it will call the WinXP partition "E:", but again, who cares? ... The OS then assigns drive letters to the first primary partition recognized on each successive hard disk. ... Because they're on separate hard drives, ...
    (microsoft.public.windowsxp.setup_deployment)
  • Re: Dual Boot Instructions
    ... If "drive" means a single partition or logical drive, then the negatives you've heard are very true. ... But if "drive" means a physical hard disk drive, then I'm in big trouble because I have SIX versions of Windows installed on my 1 TB Disk 1, my second HDD! ... The name stuck when we added hard disk drives, ...
    (microsoft.public.windows.vista.hardware_devices)