What does "validation" really do?
The description for validation, "check the backup integrity and to confirm that the backup can be recovered", is so vague, as to be almost useless. An evaluator could only conclude that it must not have very much value, since it's description is so vague. Does validation check that the content of the backup media and the media being backed up is identical, using some method such as checksums, etc? This is what most people would want. If you do that, why don't you say that is what you are doing? I really want to know if that comparison is being made, so that I can feel confident that I have a good backup.
Other useful comments I found from 3274: Validation error:
When TI validates an archive it reads the archive into RAM and recalculates the 4000 checksums/GB of archive and compares the value with the ones stored in the archive when it was created. Every checksum must compare exactly or the archive is declared corrupt.
Do not assume that just because your PC runs OK with normal use that it is impossible for it to have a hardware problem. PCs generally assume everything works and error checking is minimal. The TI validation routine is a very stringent data integrity test.
Where I have taken the time to invesigate image failures they have always been hardware related. Further evidence that it is not software related is the fact that re-imaging the same source drive using the same method results in a sucessful restoration the second time round.
From topic 8721:
it doesn't compare the files contained into the backup with the files contained into the original disk (also because these file are surely changed since the beginning of the backup process). if you receive a "success" message on validation task, you are sure that you can restore your backup.
Frederick,
The only way to verify you can restore a backup is... to restore it, maybe on a spare disk. The second best way is to restore only a few files from the backup. The third best way is to run the validation using the method you would use to do the restore (from the bootabl recovery medium, or from Windows).
Pat,
*Windows can show a valid uncorrupted backup, but since the the recovery disc uses different drivers, it may show that the backup is corrupted. In this case it will, by default, NOT recover the data.
So it doesn't make much sense to me to run a Windows validation. I always run validations with the recovery disc.
*This information is in the User Guide
I am not sure you are interpreting this right. The problem is that with different drivers, the recovery CD might not be able to access the disk or backup file at all. But if it does, a validation process on the CD will run just like in Windows: this is just basic math being done on the data in the file.
So it does make sense to run validation in Windows and to *test* your recovery CD. You can do that of course by validating the backup from the recovery CD, but experience shows that just recovering a couple of files from the backup file is enough to provide a high level of confidence that:
- you can boot the computer,
- you can interact with the app,
- you can access the backup file you need,
- the backup is not corrupted.
Still clear as MUD!!! So I need to validate every backup. Very time consuming! What do most of you do regarding validation.
Validation does not guarantee that a backup file will result in a successful, working recovery!
What validation does do is to confirm that the backup file that was created by the backup operation has not been changed after it was written to the storage drive / location. It does this by reading the backup TIB / TIBX file and calculating checksum values for each block of the file then comparing those checksums with values embedded within the file. It the checksums match, then the file has not been changed since written.
What validation cannot do is to change whether any malware, virus or corruption was present in the source data for the backup operation when it was performed. This can also include file system issues present when a backup was created but not detected or known about.