Skip to main content

Acronis not recognising a TIB file - says corupted

Thread needs solution

Hi,
I took two backups of my document and setting folder using the stand-alone CD - one with only the desktop and the other with the entire user directory. It has all my latest work on powerpoint.

Then I rebuilt my system from a drive backup - this worked OK - I'm using it now. Then I wanted to restore the desktop - and both files show up as being "Corrupted". It says "the backup Archive is corrupted. If the backup is an image, you may try to restore data from it by mounting the image and restoring intact data"

I have tried the "trouble shooting article for corrupted files" and this didn't work - it copied OK to my hard drive, but I get the same error message.

How can this be? How do I fix it?

Thanks,
Chris

0 Users found this helpful

Did the validation work initially - meaning right after the backup was done? In other word, did the TIB file start out as validated but now it appears corrupted? Did you verify the source and target disks were error-free by running chkdsk /f /r on both before doing the backup?

Gary,
I had to use the stand-alone version of the software because my XP system was dead. Both runs came back with a "successful completion". I copied the file from an external drive to my hard drive, so the chckdsk would also be OK.

Successful completion is not a validation - validation is a separate step that must be specified. Copying files has no relationship or bearing on chkdsk - errors are copied without a problem. Chkdsk is a physical check of the disk sectors.

Gary, if you validate your backup by selecting the Validate checkbox when performing the backup, do you need to run Chkdsk too? I am *guessing* that if your backup validates, then you are safe. True?

Chkdsk should ideally be run before doing any backups, and should be run on both the source and target disks. This can correct for bad sectors, possibly save files with some bad sectors, and prevent bad sectors from being included in the backup - giving a better chance for successful validation. Unfortunately, validation is not a guarantee that all is well - this whole scenario is a very big undertaking. A restore could not be successful even with a "valid" image file for a myriad of reasons - unknown bad cable, slightly imperfect connections, undetected power spikes, etc. But validation is a necessary first step. But it is our responsibility to make sure the system is in good shape before carrying out a backup. So making sure there are no physical disk errors or memory errors (which can also cause an image file to be corrupt) is good practice. Chkdsk should be run periodically as part of routine disk maintenance procedures.

OK,
I finally got it to work.

Gary - BTW - chkdsk did not fix it.

The version of Acronis on my machine is circa 2007 - version 11.0. I built the tib file with this version (stand-alone) and tried to read it with the same version - NO-GO. I copied the file to another machine that has a newer version - home 2010. I was able to open the tib file and read all the contents.

I'm Back.................

Good new.

Chkdsk doesn't "fix" any file problems. It marks off bad sectors that should not be used. If any file (TIB or other) is written to a disk with previously unknown bad sectors, there can be problems accessing the file later on because of the bad sectors. It should be run before any backups are made.

Ideally, bad sectors are marked off at the time of disk manufacture and low-level formatting, but unfortunately in reality the magnetization map does lose some information over time - just a property of magnetic media that one can't avoid. Periodic running of chkdsk finds these sectors, as well as sectors that become bad due to changes of magnetization characteristics absent at the original low-level formatting. And since most folks would not really like to wipe clean their hard disks and start over with a low level format periodically (which would help a lot of problems), chkdsk does this in a "high-level" way allowing continuing system operation.

You can avoid using chkdsk altogether. One computer I work with - this was never done, why bother with chkdsk. Then came the day (a few months ago) when the system wouldn't boot. No BSOD, nothing, totally dead. The disk was a total disaster. Just some difficulty such as ntoskrnl.exe (the core of XP) with some bad sectors! I learned my lesson the hard way.