Damaged hard drive

[yaro137]

I forgot to add that I tried Ghost from the boot floppy again but this
time it shows me that it can't find any partitions on that 250 drive.
Yes it can see it as 250GB disk now.
yaro

 

[yaro137]

I was preparing to run TestDisk and guess what happened.
The disk that was running the system for me started having
similar problems. For now it boots to Windows but after a minute
or so the system restarts. HELP
yaro

 

[yaro137]

IDE but two different computers in a row with similar symptoms?...
wouldn't that be too much of a coincidence?
Anyway I got my friend's drive connected to yet another PC making sure
it won't try to boot from it. Also I removed
RAM chips and BIOS battery from my mates computer to be sure it gets
purged. Then booted into Safe Mode
on that third PC and scanning my friend's drive with Avast Home. Hope
it checks boot sectors of additional drives.
Had to leave it there as it was taking awfully long to get to just 50%
and it's Sat evening.
Still hoping for the best although preparing for the worse. Thought
the AV will pick on something straight away but
it found nothing. Still 50% to go so there is hope.
yaro

 

[db]

the next step is to go
into the bios and see
what it states about your
disks.

does the bios confirm
you have a 250gig
disk or 40 gig disk?

you might want to press
the key for auto detect
in the bios and see.

or you may want to check
the disk's documentation
to manually enter the
configuration of the disk
in bios, like size, lba, etc.

ultimately, you may have
to simply delete that
partition and recreate
it,

ensuring that you have
designated all of the
space possible to the
partition before formatting.

personally, I would divide
the disk into thirds and make
three partitions.




--

db·´¯`·...¸><)))º>
DatabaseBen, Retired Professional
- Systems Analyst
- Database Developer
- Accountancy
- Veteran of the Armed Forces
- Microsoft Partner
- @hotmail.com
~~~~~~~~~~"share the nirvana" - dbZen

 

[db]

btw:

format the disk
using ntfs and not
fat32.



--

db·´¯`·...¸><)))º>
DatabaseBen, Retired Professional
- Systems Analyst
- Database Developer
- Accountancy
- Veteran of the Armed Forces
- Microsoft Partner
- @hotmail.com
~~~~~~~~~~"share the nirvana" - dbZen

 

[yaro137]

The BIOS is happily showing me 250GB now.
It was partitioned for the system and data indeed.
However Ghost nor ShadowProtect can't see
any partitions on that disk so I can't back them up.
Before I get my friend's disk sorted I'm scarred to
do anything on that drive.
Thanks
yaro

 

[db]

well, when you state that
all computer management
shows is the 32 gig partition,

and you see no other
indication of there being
any unallocated space
available on the disk

then something is
screwed up.

-----------------

so you may not have
any choice but to
wipe the disk and ensure
that the proper steps are
taken to partition and
format the disk using
ntfs.

-----------------

what you can do is to
connect that drive to
another pc and use that
other pc to back up the
32 gigs of data.

then use that other
computer to delete
the 32 gig partition
and to recreate new
partition(s).

then format them using
ntfs

once that corrupted drive
has been properly set up
with the partitions and the
ntfs (nt file system)

then restore the backup.

then move that drive out
of the other pc and back
into its home pc.

sometimes, restoration
of backup files isn't flawless,

so if the disk fails to boot
up then simply use a xp cd
to initiate a repair installation

the repair installation will
ensure the system files and
the security features are in
sync with the pc.

------------------

incidentally, I don't recommend
making a single large partition
with that 250 gig disk.

instead, dividing that 250 gigs into
smaller manageable partitions
is safer and more efficient.

so my suggestion is to make
three equal partitions when
repartitioning that drive on
the other pc.
--

db·´¯`·...¸><)))º>
DatabaseBen, Retired Professional
- Systems Analyst
- Database Developer
- Accountancy
- Veteran of the Armed Forces
- Microsoft Partner
- @hotmail.com
~~~~~~~~~~"share the nirvana" - dbZen

 

[yaro137]

Thanks but a couple of post before I mentioned that the 32GB was
unreadable and it was set this way, as Paul pointed out due to
incorrectly set disk jumper. After correcting that The Bios can see a
250GB partition back again but something corrupted the boot
sector. Starting the computer from a Windows CD with only my corrupted
drive connected and trying to run reinstall the system
showed me my both portions for a moment and then the computer
restarted. Same when I tried to get to the Recovery Console.
It restarts before getting to the command prompt so I can't even try
fixboot and fixmbr again. As no data recovery tool can recognize
the partitions although they recognized my 250GB drive correctly I
can't recover anything. I hoped Linux can get to the files but
it can't see any files on any of the drives. Even on the spare disk
when I put a txt file to see if I can find it under Linux I was
unsuccesful.
I'll try another distribution to see whether it works better.
yaro

 

[yaro137]

Don't know how but at least I've got my friend's PC fixed.
It's either removing the RAM and BIOS battery or the AV although
I can't remember Avast finding any viruses. Will leave my hard drive
for now till I get yet another Linux live CD as the one I tried now
wouldn't
boot.
yaro

 

[Paul]

Don't know how but at least I've got my friend's PC fixed.
It's either removing the RAM and BIOS battery or the AV although
I can't remember Avast finding any viruses. Will leave my hard drive
for now till I get yet another Linux live CD as the one I tried now
wouldn't
boot.
yaro

Now that the correct capacity is reported, you should try TestDisk.
What TestDisk does, is scan the entire disk surface, looking for
structures which resemble partitions. Based on that, it proposes
a new partition table. TestDisk is available for various OSes,
and I even have copies on several Linux distros.

http://www.cgsecurity.org/wiki/TestDisk

You should not accept the new partition table, until you've recorded
the details of the current table. Just in case you need to restore
that table later.

Symantec has a couple utilities from Partition Magic, which are
available for download. They will display partition info while
in Windows. You'd want PQEDIT32, so you can get parameters from
the table, and see whether the current partition table is intact
and makes sense or not. PQEDIT32 shows a table of numbers, and
even if the file systems themselves are damaged, it will still
show you the partition information.

ftp://ftp.symantec.com/public/english_us_canada/tools/pq/utilities/PTEDIT32.zip

In the display, there is a Partition Type field. If you double click
the Partition Type field, a list of partition types will pop up.
By reading that list, you can decode what kind of partition
corresponds to the number show.

It could be the partition table which is damaged. It could be
one or both of the individual file systems, in the partitions,
which are damaged and unreadable. Since TestDisk is going to
"correct" the partition table, if at that point you ran
CHKDSK and the partition table is not correct, then CHKDSK
could make a mess. Which is why, if trying to do an "in-place
repair" with tools like that, you want your "dd" backup copy
to undo it all.

CHKDSK or the like, is only going to be prepared for things
like FAT32 and NTFS. If there are other partition types present,
you'd need an OS and environment appropriate for them, to recover
them. (I.e. Linux for EXT2 and EXT3).

If you had three partitions, and deleted one of the partitions,
TestDisk can find the remnants of that, and can potentially add
it to the proposed new partition table. That is why you, the
operator, have to decide whether what TestDisk is doing, makes
sense or not.

If you're in TestDisk, and you want to quit the program, and there
is no "Quit" option at that menu level, you can still press
<ctrl>-<C> to stop the program.

Paul

 

[yaro137]

Thanks for great info Paul. I'll certainly try TestDisk. However as I
mentioned I am
having problems with dd. I run dd --list which showed me all the
volumes connected not
recognizing that my corrupted disk is split into two ntfs partitions
but that's probably fine
as it should copy all the drive bit by bit or rather block by block
anyway. When I run

dd if=\\?\Device\Harddisk0\Partition0 of=\\?\Device
\Harddisk2\Partition0

it gave me the following:

"written by John Newbigin <[email protected]>
This program is covered by the GPL. See copying.txt for details"

and that's all. I didn't seem to do anything so I closed it.
Not sure what I'm doing wrong.
yaro

 

[Paul]

Thanks for great info Paul. I'll certainly try TestDisk. However as I
mentioned I am
having problems with dd. I run dd --list which showed me all the
volumes connected not
recognizing that my corrupted disk is split into two ntfs partitions
but that's probably fine
as it should copy all the drive bit by bit or rather block by block
anyway. When I run

dd if=\\?\Device\Harddisk0\Partition0 of=\\?\Device
\Harddisk2\Partition0

it gave me the following:

"written by John Newbigin <[email protected]>
This program is covered by the GPL. See copying.txt for details"

and that's all. I didn't seem to do anything so I closed it.
Not sure what I'm doing wrong.
yaro

Your command is copying Harddisk0 to Harddisk2. Is that what you wanted ?
I thought your damaged disk was Harddisk2. You want to copy from
Harddisk2 to some other disk, either disk to disk, or disk to file.
if = "input file or device". of = "output file or device".

OK, try the following. This copies a single sector, the very first
sector, from Harddisk2 and places the result in file C:\small.bin .

dd if=\\?\Device\Harddisk2\Partition0 of=C:\small.bin bs=512 count=1

See if that command works OK. You would see a new file on C: after
the command completes, and the size of the file would be 512 bytes.

*******

The benefit of a disk to disk transfer, as in this (Harddisk2 --> Harddisk3)

dd if=\\?\Device\Harddisk2\Partition0 of=\\?\Device\Harddisk3\Partition0

is if Harddisk2 was in good shape, Harddisk3 would immediately be available
to use. It would appear as a duplicated set of partitions. If Harddisk2
had four partitions, after the copy completed, Harddisk3 would also have
four partitions. If you rebooted at that point, a total of eight partitions
would show up after reboot. The four original partitions, plus the
four copies on the Harddisk3.

If you do the following kind of transfer, where the volume J is a
very large NTFS one, you get a backup, but the backup is only useful for
copying back to some hard drive later. This copies all of Harddisk2
(250GB) to a single file on J: drive. J: in this case, needs to be
NTFS, to get around the 4GB limit of FAT32 volumes.

dd if=\\?\Device\Harddisk2\Partition0 of=J:\large.bin

Later, if you wanted to put the 250GB backup file, back onto
a new hard drive, the command would look like the following.
This copies the large.bin image, to a new hard drive Harddisk3.
Since the large.bin file has the partition table at the front of
the file, when it is written to the new disk, the new disk now
has a partition table as well.

dd if=J:\large.bin of=\\?\Device\Harddisk3\Partition0

I don't see much in the way of debugging options in the "dd"
program. I see a "progress" option, but I don't know what that
does.

Please be careful with the command syntax One mistake
and you could lose a *lot* of data.

Paul

 

[yaro137]

You're right. I got this the other way round lol.
Will try again today after work and then TestDisk.
Thanks
yaro

 

[yaro137]

Still creating the large.bin file. It's an old machine so it takes it
aaaages.
but at least it looks like it works now. Thanks Paul.
As only I get there I'll let you know how the DiskTest did.
Cheers
yaro

 

[yaro137]

It finished copying. Now this is really strange. Windows can see that
320GB drive as a 29.9GB disk. Space used 64MB.
The large.bin file size somehow dropped down to 0KB. In the system log
I found:
"Changing the disk signature of disk 2 because it is equal to the disk
signature of disk 1.!"
and next
"The file system structure on the disk is corrupt and unusable. Please
run the chkdsk utility on the volume D:."
Looks like TestDisk is my last hope.
yaro

 

[Paul]

It finished copying. Now this is really strange. Windows can see that
320GB drive as a 29.9GB disk. Space used 64MB.
The large.bin file size somehow dropped down to 0KB. In the system log
I found:
"Changing the disk signature of disk 2 because it is equal to the disk
signature of disk 1.!"
and next
"The file system structure on the disk is corrupt and unusable. Please
run the chkdsk utility on the volume D:."
Looks like TestDisk is my last hope.
yaro

When you did the "dd" copy, there should have been a status message
when the copy was completed. Something about how many bytes or
records were copied.

The spare disk holding the "large.bin" file, should have been formatted
NTFS. If it was formatted FAT32, the copy should have stopped at a size
of 4GB, which would represent a failure to copy the whole thing.

I can't explain why the copied file size is zero. It sounds like it
is pretty important to figure out exactly what happened. You
may not have a good backup at this time.

If you use HDTune 2.55 from hdtune.com , you can do a surface scan of
the damaged disk, and see if any CRC errors are reported. "dd" will
only work well, if there aren't a lot of CRC errors. You would need
to dig up a copy of "dd_rescue", to copy a disk with a lot of CRC
damage. and that might be something you'd do using the Linux OS
and a Linux Live boot CD.

The general syntax for the dd command is like this

dd if=(source) of=(destination) bs=block_size_bytes count=number_of_blocks

If you use the command in the following way, it runs pretty slow. It copies,
until either the source device is exhausted, or there isn't enough room on
the destination device.

dd if=(source) of=(destination)

If you specify a block size, using the "bs" value, the copy process works
in "block size" chunks. This makes the command run much faster, at
say 20MB/sec transfer rate. The trick then, is to make sure that
the block_size * number_of_blocks is such, that all the data was
transferred.

So, let's try and craft some good numbers for "bs" and count. I use
the Linux "factor" program, as a quick way to factor a number. I keep
Linux (Knoppix 6.0) in a Virtual PC session for this purpose.

33820286976 = 2**13 * 3 * 3 * 7 * 19 * 3449
= 516096 * 65531

To copy the disk relatively quickly, the command looks like

dd if=(source) of=(destination) bs=516096 count=65531

When the dd command is complete, it should say "65531 records transferred".

The block side of 516096 is 1008 sectors of 512 bytes each.
If a block size is not specified, it is possible the
transfer operates in chunks of single sectors at a time,
which would cause it to run slower.

Since a lot of DMA transfers are involved, the fact the
computer is old should not be a factor. Direct Memory
Access hardware transfers, remove the burden from the CPU.
And the dd copy command should be using those features on
both the source and destination hard drives.

Paul

 

[yaro137]

Hi Paul. Good to know that you're still reading this.
I fired up HDTune and it shows me my two partitions
on that corrupted disk. It also points to Spin Up Time
whatever it means failed. Also Realocated Sector
Count is highlighted in yellow although the status
here is OK.
I'm just running the Error Scan on it and at the same
time I reformatted my spare disk (it's NTFS indeed) and
running check disk on it.
yaro

 

[Paul]

Hi Paul. Good to know that you're still reading this.
I fired up HDTune and it shows me my two partitions
on that corrupted disk. It also points to Spin Up Time
whatever it means failed. Also Realocated Sector
Count is highlighted in yellow although the status
here is OK.
I'm just running the Error Scan on it and at the same
time I reformatted my spare disk (it's NTFS indeed) and
running check disk on it.
yaro

The yellow statistics likely are not good. Spin Up Time
problems may not be the fault of the drive (a weak 12V feed
to a drive could also be responsible, such as inside
an external USB enclosure). My current drive isn't perfect
on Spin Up Time, but I'm not concerned about it.

But if I see Reallocated Sectors, that is the
responsibility of the drive alone. So that would be enough
for me to consider retiring the drive, once the data has been
recovered. Reallocated sectors are all part of the drive
maintaining itself, so a couple is not a problem. But
if there is a growth rate observable, that could mean
there is contamination inside the drive.

Some people have opened up the HDA on a dead hard drive, to
find "dust" from the surface of the platter. So it is possible
for a drive to create its own contamination internally, when
something scrapes. While there is an air circulation scheme
and filter pad inside the drive, to take care of small amounts
of contamination, a failure of the platter surface (corrosion,
or a head crash), may pollute the surface of the disk and
cause further problems. The inside of the drive could be
as clean as can be, or it can be quite filthy in there when
the drive fails.

In any case, once you're got your "large.bin" file and it
is the right size, you have less reason to be concerned
about what SMART shows. The "large.bin" file is your
backup, and your insurance if the broken drive fails
completely.

Paul

 

[yaro137]

That's really strange but HDTune Error Scan gave me a negative result.
It found no damaged sectors. I think I'll give dd another try.
yaro

 

[yaro137]

So far so good. My large.bin reached 45GB so it went through the first
partition of the corrupted drive and it's still growing.
yaro