TI9 Build 2289 Secure Zone Error

TI Ver.9 Build 2289

Still error archiving to "Secure Zone" with "Check backup when completed" selected.

1) Archive image to "Secure Zone" with "Check backup when completed" NOT selected, No Errors
2) Manually check this image archive, NO Errors
3) Archive image to "Secure Zone" with "Check backup when completed" selected, Completed with Errors....5(0x640005)
4) Manually check this same image (Windows), No Errors
5) Manually check this same image (Recovery CD), No Errors

Is there still a problem or am I missing something?

Regards,
Bill

 

Hi Bill,
You are correct in your findings. I can reproduce them exactly on my XP computer. So this bug has not yet been fixed in 2289.

However, from my own viewpoint, I do not use the check image process. I am not convinced that it is a worthwhile facility. For starters it does not go back and check the image with the original data. It does not fix any errors but in some circumstances reports false positives.

Xpilot.

 

Hi Xpilot

(pause as he takes a big intake of breath!!) Carrying out an image check is a lot better than relying on good fortune. Part way through an image restore is not a good time to find out that your latest backup really was corrupt after all. By then your destination partitions will have been deleted as part of the restore process.

If the check image wizard reports the backup as corrupt I would recheck it and, if still reported as corrupt, create a new full backup immediately under a different file name and verify that.

I would assume that TI calculates some form of Cyclic Redundancy Code (CRC) and includes that information within the image for each physical data write operation. During an image check, TI will read back the image data, calculate new CRC checksums for each data read operation and compare them with the original CRC bytes recorded within the image. If they match, the image is good but if not then the image is flagged as corrupt. However, this assumes that the CRC bytes themselves were written to the media without error. A classic "catch-twenty-two" situation I guess!!

Regards

 

Hi Memorcaman,

In my innocence I assume, when a backup finishes with the message that it has sucessfully completed, that this what has actually happened. If the program is worth it's salt it will have done all sorts of internal checks to ensure image integrity at that point. So why should it be necessary to run an additional integrity check? This is particularly relevant when the image is stored in a secure zone and/or on a separate drive where it is extremely unlikely to suffer from errors introduced by viruses or operating system oddities. In any case most users would keep more than one image that could be used for restoration.

Consider this scenario. Your main drive blows up and all you have is it's image on a separate drive. I would not run an integrity check on this image because that would not improve the situation in any way. The check would not repair the image if it was damaged, it would just say it was good or not so how is one better off?

I agree that it would be a tense moment if one were to overwrite ones operating system and many years worth of data from an image but remember this is never necessary in a disaster or in testing. I do not rely on good fortune, I restore the whole of my main drive to a replacement drive for each version of Acronis Drive Image that I decide to run with. So when disaster strikes down the main drive I just replace it with another and restore from the latest image. I also keep well clear of the catch 22 Loop!

Xpilot

 

Hi again Xpilot,

My apologies in advance if the following sounds like grannie teaching you to suck eggs!!

When Ti informs you that it has successfully completed the image creation tasks, what it's really saying is that it has successfully copied and packaged up all the necessary data and handed them over to the "Post Office" (motherboard hardware) for onward delivery to the correct "Distribution Center" (HD electronics). The packages will include a contents list (checksum) and the "Post Office" will have returned a "receipt note" to TI for the number of packages received but will not have checked their contents. Like most other applications, TI assumes that the "Post Office" will deliver all packages intact to the "Distribution Center", which in turn will decide where they will be delivered and stored for safe keeping (sectors/clusters on the hard disk platters).

When TI carries out an image check it asks the motherboard to retrieve copies of the stored data from the HD. The HD integrated electronics will copy the data held on the platters, repackage them and return them to TI via the motherboard's hardware. On receipt, TI will count the number of packages and check their content against each contents list (original checksum). If there is a discrepancy in either the packages or their contents, TI will flag up that there has been a problem. Now either TI has miscounted the packages and/or incorrectly filled in the original contents lists, or the convoluted hi-speed Distribution Chain (motherboard and HD) has failed somewhere along the way. I will leave it to you to decide who is the most likely culprit!!

Granted, in this case, finding out either before or during a restore that the image is corrupt would not repair a damaged hard drive. However, it would calm my nerves greatly to know that my image could be successfully restored to a replacement drive.

Many users (myself included) do not use the disk clone method for "disaster" recovery. We experiment (play?) with lots of different software/software updates/device drivers and always create a current image (and immediatley verify it!!) before changing the status quo. If our system then gets severely screwed up it's nice to know that a quick restore from a known good image will have us up running again within a few minutes. Personally, I also run a simple batch file to backup my important data (work folders, emails, My Documents, Favourite etc.) just prior to creating or restoring any image. I then run a second batch file immediatly after an image has been succesfully restored in order to copy the up-to-date data back again. Simple I know but it works well for me.

Regards

 

Hi Menorcaman,

Thanks for your detailed explanation of how images are created and then stored. I am still not entirely convinced that it necessary to run the verify image process. I would have expected that when Windows takes over from True Image to finally write the image to a hard drive any problems would be highlit by an error message. Or am I to understand that there are no checks or other verification to ensure the accuracy of data written to a hard drive under Windows?

I assume in your second paragraph you are referring to the HD where the image is stored and not to the drive where the original data is held. This would be consistent with my own observations when testing the verify image program on an image stored on a USB HDD as all the activity takes place there and the originating drive can be disabled or even removed.

I have never used the cloning method for backup or anything else. My poor wording of my test methods must have given that wrong impression. To clarify, I store backup images on separate HDDs. One is installed as slave to the main drive. The other is in a USB 2 enclosure where I also store images as a second line of defence.
When a new version or build of True image comes along I install it and run it to create images on the internal slave drive and on the external USB drive.
The actual test consists of removing the master HDD, pretending that it has failed, and putting in another HDD that could be brand new or one that I have to hand. With no further preparation I boot from the recovery CD and restore an image from the slave hard drive and check that all is well. I then repeat the process with an image restored from the USB drive to make sure that that backup can also be restored.
So that is how I calm my nerves by having two different backup media and doing actual restores to replacement drives whenever the backup system is changed.
I make day to day checks on image creation by examining the logs and from time to time plugging the images in and exploring them.

When TI can run verification of an image after creation within a secure zone and not report false positives I might tick the necessary box and sleep even more soundly in future!

Xpilot

 

Hi Xpilot,

Thanks for the additional clarification on your backup and testing methodology. I now understand where you are coming from.

I too image to multiple media; second internal HD for short term backup, external USB2 HD for medium term and DVD RW for somewhat longer term.

I know the proof of the pudding is in the eating but unfortunately I don't have the luxury of a spare HD that I can substitiute in order to test an image immediately after its creation. Given the number of times I create images I doubt I would feel inclined to that anyway . So I guess I'm stuck with TI's Check Image Wizard! Having said that though, I always play safe and assume TI is correct when it reports an image as corrupt (a very rare occurance in my case and usually when I've attempted a fast burn to optical media). I then immediately recreate and verify a new one. Call me lucky if you like but I've never had an actual restore failure due to corruption of an image that had previously passed TI's verfication check (said he whilst frantically looking around for a piece of wood to touch!!).

Regards

 

Hi again menorcaman,

My spare hard drive is one that I retrieved from a PVR machine that I upgraded to store >100 hrs. of digital TV programmes. If I had not got this one I would have bought one anyway because I regard it in the same way as a spare wheel for a car. You hope you will never need it but when you do it is great to be able to pop it into the computer and be up and running again in a few minutes!

My computer desk is a DIY customised reclaimed ex-dining
table so I have plenty of real wood to touch when I feel the need!!

Cheers Xpilot.