Skip to main content

Problem with Build 6525; Image Recovery Fails with "Index Corrupted" Error

Thread needs solution

I have used Acronis True Image 2009, 2010, 2011, 2013, 2014 and now 2015 to implement the following strategy with no problems until now.

My most critical computers have the "C" drive mounted in CRU Dataport drive cassette http://www.cru-inc.com/products/dataport/dp3_sata/ which allows me easily unlock and pull out the C drive and replace it with another C drive as part of my backup strategy. I rotate 3 "C" drives through the machines so I have backup images ready to go in case of a hard drive failure, or the drive image becomes badly corrupted.

I use ATI to back up the latest drive image onto a permanently mounted D drive, then rotate 1 of the 3 C drives into the machine and then use ATI Recovery to re-image that drive to the latest level and run on that drive until the next month, or less time if there is a major software upgrade planned.

This strategy assures me that 1) the image will actually recover in the event of a real failure, and 2) have backup drive ready to go, if a HDD failure occurs.

This has worked well up through ATI 2015 Build 6053 Hotfix 1..

After upgrading to the latest level ATI 2015 Build 6525, the image recovery fails with a "index corrupted" error leaving the target drive wiped with no image. I have tried perform the backup/recovery several times storing the backup image in both the ATI Secure Zone and onto the D Drive saving the backup image outside of the secure zone.

I do the backups using ATI in Windows and the recoveries by booting the Rescue Media CD. The backups are done using the "+create new backup" function to make a new full independent image. I get the same failure each time with build 6525.

Next I am going to make try a backup / recovery using the Rescue Media CD still at the Build 6053 Hotfix 1 to see if it confirms this is a problem in Build 6525.

Anybody else run into the problem with Build 6525? Any fix available for this?

Attachment Size
ati2015b6525log1.jpg 128.36 KB
ati2015b6525log.jpg 116.67 KB
0 Users found this helpful

Try to mount the image to a local disk Y:, for example, in read write mode, then run chkdsk Y: /R. Then unmount the image. If any changes were made, ATI will have create an incremental backup on top of the image you mounted. Try to restore that inc (the original chain 03is needed as well as the corresponding "full").

Ah OK! Well, there you go. Unlike with 2014, you cannot do this any longer.

Try to run a chkdsk X: /R on the original disk then, then do the backup, then the restore.

Dan Eddleman:

I use something similar, except I use the boot media to bring up ATI, then I make two cloned images of my C: drive. This way Everything on my C: drive is there and then I can substitute one of the two clones for the good copy I am cloning. If everything is good to go, then I continue to use the clone as my C: drive knowing that I have a good copy in reserve plus another. Over the years I have found this to work better than making an incremental. I usually do this every two weeks as most of my changes are not very important, but it protects me from an errant malware that my checker fails to recognize. I usually test the second clone during the week, but keep it separate as insurance from a catastrophic failure. I know that ATI has all sorts of neat modules that are fun to play with, but at my advanced age I cannot keep up with all the nuances those require. Drives are very cheap now and that strategy works every time for me.

WBird... we are on the same page with slightly different technique (cloning in lieu of backup/recovery) regarding the use of ATI with the objective of being prepared for the major failures...

Even though I check the condition of the drives fairly often it turned out the problem that the indexing error was referring to was in fact the Windows indexing was corrupt for about 8 clusters in one or two files. The error message (not knowing anything about the internals of the ATI created backup up image file layout) wasn't clear to me whether the error was referring to an indexing issue inside the tib file, or if it was in fact the Windows NTFS index that was corrupted.

If the error message had said "Windows NTFS index corrupt" it might have saved me a bit of diagnostic time.. I do have in my boot up scripts a call to run FSUTIL.EXE which will indicate a drive is "dirty" if a sector goes bad, but.... new lesson learned ... other things can go wrong and FSUTIL doesn't flag them or give any warning.. My drive with the indexing problem was still showing clean in the FSUTIL run.

Given how long it takes CHKDSK /F option to fully check a 1 terabyte drive (about 3 hours), and that the drive must be dismounted.. I wish there was a way ATI could either do a bit more checking and alert you at back up time that the image is no good and will not restore (probably not possible) OR at least give the user the ability of go ahead and do a restore with (with a couple of files corrupt) rather than kill the whole recovery process, leaving you with no back ups at all.. I suspect other errors detected by CHKDSK would similarly kill an the image recovery process. I must admit I haven't dug through the entire ATI documentation package and maybe this info is in there somewhere in the details. Would be interesting to know if the drive cloning process similarly fails...

I had this same scenario happen a year or so back on a failing drive that sectors were going bad.. one bad sector written into a backup kills the entire recovery..which of course your won't find out until you really need it. Had to rebuild that machine from scratch as a result..and that's when I started running the FSUTIL utility in the boot up scripts, thinking the dirty flag was sufficient indication to let you know the image is corrupt enough that it won't restore.. wrong..

Lessons learned.... 1st.... don't even think of doing an ATI backup without running chkdsk with full checking first. 2nd, unless you use the recovery feature (or the cloning option as suggested above) and with enterprise server style drive cassette housings for the HDDs where a spare C: drive or clone drive can easily be swapped in for the recovery test, there is no confidence that the image backup will actually restore. You have to have the cassette mount drives or other drive mounting arrangement to do the test.. You won't dare to a recovery test onto your one and only golden C: drive. If the recovery fails for any reason, you will be left with a wiped drive...

Finally, after reading the dissatisfaction many others have expressed about the removal of functions in ATI 2015, and this experience, moved my already existing dissatisfaction with ATI 2015 function removal to the tipping point in that I have removed ATI 2015 on two machines and reverted to ATI 2014. I really want the functionality in ATI 2014 that was taken out of 2015. I have applied for the 30 day refund for the 3 license ATI 2015.. I will leave the single license ATI 2015 on one other machine, just to see if any thing is done about restoring some of the needed functions over time..

I've always assumed that a validated backup would install, and I wouldn't have to worry about it being corrupted. Am I mistaken in this?

From what I have seen I think the answer is Yes....many of us are mistaken.. I didn't mention in the above posts I validated the backups and they passed..

See comment below from the ATI 2014 documentation I think with the ATI Policy defaults, all the verify operation indicates is that the tib file created by ATI is intact...

From what I have seen pre-existing errors in the Windows file structure faithfully recorded by ATI are not detected until ATI is actually trying to write the file structure on the hard drive during a recovery operation. And when they are detected the entire recovery operation is aborted due to the error. At this point the drive being written to has already been repartitioned during the recovery process and earlier data lost... This is why I never... unless my back is against the wall do a recovery to a one and only functioning (albeit some problems) C Drive.

I think they should have a bypass function to allow defective sectors or files that are hosed up by index errors to write null records in place, rather than kill the whole recovery process. The user would have to make the choice if the are relatively minor errors are an acceptable tradeoff in fixing the larger issue that brought about the need to do an image restore. From the reading below, looks like there may be ATI Policy settings to permit this

In my case I had a couple of files whose index was messed up.. I would gladly accept that problem (and fix later) than having the entire drive image restoration process fail.

Quotes below from From ATI 2014 User Guide

Section 7.1.1.2 page 106...
Boot from the rescue media and validate the backup you want to use for recovery. This is necessary because, when a backup is validated in the recovery environment, the program sometimes declares it corrupted though it has been successfully validated in Windows. This may be due to the fact that Acronis True Image 2014 uses different device drivers in Windows and in the recovery environment. If Acronis True Image 2014 considers the backup corrupted, it will not proceed with recovery.

The above in bold is an unsettling statement... validation in the Windows environment is not the same as validation in the recovery environment

6.5.11 Error handling
When the program encountered an error while performing backup, it stops the backup process and displays a message, waiting for a response on how to handle the error. If you set an error handling policy, the program will not stop the backup process and warn you about an error with a message, but will simply handle the error according to the set rules and continue working.
You can set the following error handling policy:
 Do not show messages and dialogs while processing (silent mode) (the preset is disabled) - You can enable this setting to ignore errors during backup operations. This feature was mainly designed for unattended backups when you cannot control the backup process. In this mode no notifications will be displayed to you if errors occur during backup. Instead you can view the detailed log of all operations after the backup process finishes.
 Ignore bad sectors (the preset is disabled) - This option is present only for disk and partition backups. It lets you run a backup even if there are bad sectors on the hard disk. Although most disks do not have bad sectors, the possibility that they might occur increases during the course of the hard disk's lifetime. If your hard drive has started making strange noises (for example, it starts making quite loud clicking or grinding noises during operation), such noises may mean that the hard drive is failing. When the hard drive completely fails, you can lose important data, so it is high time to back up the drive as soon as possible. There may be a problem though – the failing hard drive might already have bad sectors. If the Ignore bad sectors check box is left unselected, a backup is aborted in case of read and/or write errors that could occur on the bad sectors. Selecting this box lets you run a backup even if there are bad sectors on the hard disk ensuring that you save as much information from the hard drive as possible.

Ok there is an option to deal with bad sectors present, how about other errors chkdsk can find? Will Recovery use the same settings that Backup does? On my machine that experienced the drive failure, bad sectors did not stop the backup, but stopped the recovery.. Need to check the ATI Policy defaults.. Have never touched them....

6.6.2 Testing that your backups can be used for recovery
Here are some recommendations:
1) Even if you start recovery of the active partition in Windows, the program will reboot into the Linux environment after the recovery process starts. This is because Windows cannot be left running during the recovery of its own partition. So you will recover your active partition under the recovery environment in all cases.
If you have a spare hard drive, we strongly recommend you to try a test recovery to this hard drive. It should be done after booting from the rescue media which uses Linux.
If you do not have a spare drive, please, at least validate the image in the recovery environment. A backup that can be read during validation in Windows, may not always be readable under Linux environment

Strongly agree with this statement... to use a spare drive to test a recovery before overlaying a still working drive (but with problems)

Still reading the ATI documentation end to end.... If anyone can shed further light or if I am not seeing things correctly above, please elaborate..

Dan; O-Wow ! this is quite a writeup, while you are shown as a "beginner", I doubt that applies to your computer useage. Will make note of this writeup, for future reference, hopefully before making some of the noted mistakes. Thanks for the information. B