"Bad sectors on disK" error

I am using TI 11 build 8053 with xp home sp 2. I scheduled a task to create an image backup archive of my entire system disk and validate it. TI made the archive. During validation, I got this error message:

Error 7 3(0x70003)
Failed to read data from the disk.| A possible reason might be bad sectors on the disk.: None

However, I ran chkdsk d: /v/r where d was the system disk, and chkdsk d: /v/r where d was disk where image was stored. No problems were reported in the log files.

Can you help me with this?

 

When ATI makes a backup, it inserts a checksum every so often. When you do an ATI validation, it reads the fils and recomputes the chuck sums from what it's read and if any one doesn't match what was originally inserted in the file, it declares the file invalid.

This can happen if ATI is unable to properly write the file inthe first place or to read it afterwards. This can be due to inadequate drivers, if you're using the ATI BootCD.


It can also be due to a bad harddisk but your chkdsk test suggests that it's not a hardware problem but an ATI prob. which would require diff tacks depending on how the problem cropped up. What kindof drive (usb? -- are the cables good, are other usb devices plugged in --are you connec to a USB host or daisy chained, are you using the BootCD . . . Sp if you tell us more we might be able to better help.

 

The image is made on an internal hard drive that is not a system disk. I am not using the boot cd. Please let me know if you need more info.

 

I agree with Shieber.

Can you validate the archive on the external HD using the TI rescue bootCD? You must be able to do this to restore the active partition.

If you have an extra partition on an internal drive you could try copying the archive file(s) to it and then attempting the validate using the TI rescue CD and then the restore if the validate is successful. TI needs to run in the Linux recovery environment to restore the active partition so even if you start the process in Windows the computer reboots and loads the Linux stuff. This is the same environment that is on the TI rescue CD.

If the above copy method fails, run a free checksum calculator and see it the archive file(s) checksum(s) on the external agree with the copied archive file(s) on the internal. I have added the optional plural in case your archive is spread out over more than one file. You need to do this step on each file. Note that if you do a TI validate, it will see all the files as part of the archive so you only need to select one .tib file to have the whole archive validated.

 

I'll try to validate using the cd, as you suggest. Will report back tonight.

(P.S., the backup image is not on a USB drive. It is on an second internal hard drive that is not the system disk.)

 

Hello phrank,

Thank you for choosing Acronis Disk Backup Software.

We are sorry for delayed response.

Please download the latest version of Acronis drivers and install it with disabled logging.

If the issue persists, please collect some information to let us investigate it thoroughly:

- Reinstall Acronis drivers with enabled logging;
- Reproduce the issue and collect the log file without closing any application windows (including the error message windows if there are any). The log file will be created at C:\ . The name of the log file will be snapapi [date-time].log

Please create Acronis Report as it is described in Acronis Help Post.

Then submit a request for technical support. Attach all the collected files and information to your request along with the step-by-step description of the actions taken before the problem appears and the link to this thread. We will do our best to investigate the problem and try to provide you with a solution.

Thank you.
--
Marat Setdikov

 

Do I really need the new driver? I ran chkdsk thus:

chkdsk d: /v/r >c:\chlogD.txt , where d is the drive on which the archive is stored.

for step 3, the log file reported:
"Cleaning up 1 unused index entries from index $SII of file 9.
Cleaning up 1 unused index entries from index $SDH of file 9.
Cleaning up 1 unused security descriptors.
Fixing mirror copy of the security descriptors data stream.
Security descriptor verification completed."

Next, when I tried again to verify the archive, it was a success. I concluded that the problem was not with TI, but with drive d (which I will soon replace).

Should I install the new driver anyway?

 

OK, you said that you ran CHKDSK /r before, and it didn't solve the problem. You ran it again, and now the problem is solved and you can validate. Is that correct?

That sounds like a hardware problem, so you wouldn't need new drivers. If the problem reappears, than it sounds like a dying drive. Some drives die with bad sectors, but others die due to logical problems due to failing chips. It sounds like your drive may be in this latter group.