Why validate?

Does this function even work in ATI 11?

It seems that many are saying it does not reliably indicate file corruption.

So far, every image I have made with ATI 11 in vista 64 has come back corrupted when validating.

I have no idea if this means my images are no good or what?

 

My first image made by ATI 11 Home also failed validation. However, i was still able to mount the image and extract files.

I'm not sure what this means.

 

Although a fan of Acronis I have never been a fan of validating. I have made and restored several images with Acronis 11 without problem. I haven't bothered to validate any image since starting with version 6. I work on the basis that the only way to find out if an image is any good is to restore it. If an image ever failed ( not happened yet) then I would simply use the image made the day before.

 

My opinion on validation depends on how you restore. If you are going to immediately restore your backup to another drive, then there is no point is wasting time on validating the image.

However, if you mainly create images and don't restore them, then I recommend you at least run a validation of them. I say this because there is the possibility that the media may be bad. I had this happen on a hard drive. If I hadn't run a validation, then I wouldn't have known there was a bad sector on the drive where I saved the image. I ran chkdsk /r on the drive to fix it, then redid the backup and it validated okay.

TI can usually mount images that fail to validate or restore. This allows you to at least be able to get most of your files out of images that are considered corrupt.

 

When TI validates an image it calculates a checksum for every 256K bytes of data and includes it in the archive. This is 4000 checksums per GB. When it validates it opens the archive, reads the data and recalculates the checksums. They all must agree perfectly and if they don't it declares the archive corrupt. In real-life terms this means that if you have a 10GB archive and 1 bit out of the 80,000,000,000 (base 10) bits is bad the archive is rejected. When you mount the archive this test is not applied and you can access the data file-by-file. To what degree this is successful depends on where the bad bits are located in the archive and how much is bad.

I always validate in Windows because it is relatively fast and it does give me some degree of confidence that all is well. For the nth time, you must validate with the rescue CD a few times to ensure your hardware is compatible with the Linux environment. You should also do a few test restores. Once you have confirmed that your PC and the Linux rescue environment work properly together you can validate in Windows with confidence. A common problem is people buy TI, validate only in Windows, think all is well and then have to do a restore using the rescue environment. This craps out on them and they don't understand why a validated archive didn't work. Well, the archive was validated in Windows which doesn't guarantee the Linux recovery environment works on the machine.

 

So basically you're saying validation is useless.

The only real way to know that an image works correctly is to go through a number of time consuming steps (including test restores and more validations). Even then, all this only provides "some degree of confidence."

What kind of program cannot reliably process its primary function?

The reason I bought this program was to make one image I could restore to every 3 or 4 months, and it seems I cannot be sure it can even do this!

 

Real backup software calculates CRCs and inserts in recovery blocks at a configurable interval so that corrupted data blocks can be recovered. Sure it makes the backup larger, but I'd rather have a valid recoverable backup than save a few Mb of storage.

 

Well I guess once you have a good validated image, you could always create your own PAR2 parity files or similar.

 

No, I'm just saying you should make sure when you first install the program or make any significant hardware changes, say a new USB drive, that you can validate in the recovery environment. If you can, then it means your system works properly with the Linux environment and then the Windows validation will suffice.

What's so surprising about testing the restore mechanism? Until you've done some test restores with any backup program you basically are in the dark.

I've restored many, many times on my PCs and the only problem was 2 marginal SATA cables that came with an Asus motherboard. The validate failed. When I looked in the XP Event Viewer, errors had been detected on bootup and the recommendation, to my surprise, specified changing the SATA cables. I would say the usual experience with TI is that once you confirm it works, it works all the time. Like other PC apps it assumes your hardware is working properly. The high data rates and the sheer volume of data transferred with the stringent validation process will uncover errors that are far less likely to be observed in the regular operation of the machine.

 

Validation tells you if a backup file is a good as it was when it was created. It will tell you if it gets corrupted thereafter. What it seems to not ever do is compare what's in the backup fiel to the source. I think ATI assumes that, if the file reads (from the source) during backup creation occured without file system errors and the writes (to the target) occurred without file system errors, then the backup ahs the right data. Thereafter, validation tells you if a backu file has been changed by even one byte -- well it's a checksum method so, conceiveable two errors could offset each other but it's very unlikely that condtions that produce errors will cause jsut that situation to happen and no other detecable errors.

If someone has better info of backup integrity, please jump in.

If you can validate, then whatever you are doing with the backup files (ciopying, moving) is not corrupting it. If you can do a test restore on your set up, then you can remain confident that, when you need to do a restore, ATI can handle your set up. Since restores are done from the Boot CD, booting from the CD, confirming it can see all your drives properly, and even do a full out restore, at least once, is a good acid test. Since we're talking about the security of your system and its data, an acid test is a very good idea, whatever backup program you are using. You don't need to do the acid test for every single backup.

 

Agreed.

I started using Acronis 4 years ago and currently use 9.0, 9.1, 10, and now 11. Some days I only Image one machine - some days I might make 10 Images. Just guessing that 4 years may have produced 1000 plus full images
and as many if not more restores --NONE of which have failed.

So why validate ? when running a new build or on a new machine ? but once
you have a few good images I don't see that it makes much sense to validate every time. Even if a restore fails - so what ? just use another image.

As far as I can tell a version of Acronis either works with a system or it doesn't. Once a version of Acronis has been tested and found to work that's it - end of story - it works.

 

You've had better luck than many others. Some get an occassional bad backup, fewer get them more often, and a rare few can't get a backuto validate for love nor money.

If your system reads and writes files as reliably as you have reported, then continuing to do validations would be a waste of time. I pretty much skip vaidations also except when something has gone wonky -- say Kaspersky locked something up resulting in an ATI crash during a backup task -- in such a case I'll validate jsut to see if the file was corrupted during the event.

Running a validation from the bootcd is one way to partially test that the Bootcd genrally can read the backups on your set up. So doing it at the very least, once, on each set up is important.

And even if the Boot cd can read your backup, it might not be able to write to your target driver during a restore, so you need to test that at least once.

 

I took your advice and tried to validate the images in the acronis start-up manager environment.

I have one full C: image created with ATI 10 that validated correctly using ATI 10 previously, two diff images created with ATI 11 from that full image, and another independent full C: image created with ATI 11 (all of these images are in a secure zone on a different internal disk, in chronological order as listed).

The validation indicated corruption as it did in windows, unfortunately even for the first image that previously validated correctly with ATI 10.

I’m inclined to further take your advice and attempt a restore, but fear these images will not work, and I will be left with ether a messed up system requiring reformat, or will be forced to restore to a point well enough in the past as to be painful.

Any thoughts on what I can do?

 

2 thoughts:

(1) If you restore to C: and it fails that's it you will have to restore another image or
re-install. This is because the first operation in a restore is to delete the drive or partition that is being restored to.

(2) You have your images on another drive. Do you have or could you make another empty partition on this or on any other drive ? If you are able to restore to another partition this may help you determine if a particular image is any good. You will not be able to test if it boots etc but it may help to see if there is any problem with restoring the files.

 

Longview has it correct, if the restore fails you end up with unallocated space and will need to restore another image or reload. There is little reason to expect that an image that won't validate will restore correctly. Not impossible but not probable (in early versions of TI9, this wasn't the case due to a bug but that was then).