Validation - how does it work?
For some years, True Image versions have included a validation process, which the 2020 user guide says should be used with the system drive backup, at least. but tests showed that validation takes a significant time to do, so I like many haven't used it. That's probably going to change, since a recent back completed OK, restored OK, but a boot file in the restoration gave a checksum message.
So, this topic is requesting an explanation of how the validation process works, an explanation of why validating seems to take significantly longer than just an ordinary backup.
Hi En,
Thank you. That's informative, but not what I expected.
What created the question was a backup, un-validated file that was recovered Ok, but on the following start there was an OS signature problem with the boot loader that was part of the backup and the machine was dead - would not boot. The windows notice indicated that signature verification could be turned off but there nothing in the error screen that did that. A stressful problem that I still have not completely rectified.
The guide remarks about validation seemed aimed at that very issue, but there's not even a brief description of how the process works: thus the question. What I'd assumed was that the backup created would have a computed signature for the file(s) in it that was 'validated' or matched against a similar signature already in the original source file, as a way of detecting corruptions (bad sectors? dropped bits or bytes in the process?). However, what you say seems to indicate that validation simply computes a signature in the backup file and compares with itself. There seems no way that could detect a corruption in the files being backed up, either in the source or the backup itself. or have I misunderstood??
A test backup today on a C drive using TI2020 with a full and validated backup took 9 mins to generate 32Gb in 2 tibx backup files, and a further 5minutes to validate. At the end there was a message that the backup was valid. That link in your response about validation failures doesn't talk about failures, which I'd be interested in. More specifically, what sort of failure and the action needed.
David, validation can never guarantee that the contents of the source disk does not contain any form of corruption or corrupted files. Acronis would report if it encountered any bad sectors during the backup process, and this should be shown in the logs.
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.
Hi Steve,
Understood. Much like the old DOS /v flag on a copy operation.
I've understood that vendors embed signatures of software files within them when created. Certainly, in this case MS seems to think so, at least for their stuff. So validation of a backup of those files could not only verify that the written backup is good, but also compare the signature of the written backup to the those within the source files to identify if the source had "issues" (what a mild way to describe bit or byte corruption, or bad sectors . .), and as part of the event I described the fixit tech mentioned some backup software that did that. I suppose that not all software has signatures but if the OS components from MS do, then a valid backup copy of the C drive should be able to check not only if the backup copy was written correctly, but also if the source file was not corrupted before it was backed up. At least, such an approach should enable a recovered PC to start, even if some of the apps on it have problems: re-installing an app is easy enough, fixing a buggered OS that will not boot is near impossible - or so I thought until mr fixit did just that.
Sidebar: is there way to set the community account to let me know when a post has been replied to?? rather than keep coming back to it to check every few days.
David, the later versions of Acronis such as 2021 and ACPHO do perform more filesystem checks as part of the preparation for the backup operation though this does have an impact on the overall performance and time needed. This can never be as intensive as using the tools provided by MS with Windows which in themselves can take hours to run at times (i.e. using DISM /Online /Cleanup-Image /RestoreHealth and SFC /scannow), so there has to be a compromise in terms of what is potentially possible and what is actually done by Acronis!
Validation of disk images can never be used to compare against source data because that source data is continually changing and has to be captured as a moment in time snapshot by Acronis using VSS, then processed before being written out to the .tib / .tibx storage file on disk. Snapshot data is not persistent over time to allow any validation to be performed using it at some later date or time.
For the above reasons, users need to employ a backup strategy that is intended to mitigate against possible / potential issues that may arise, i.e. having multiple backups stored in different locations / on different media along with using more than one backup application. Separation of OS + Applications from Data should also be a key consideration in any backup strategy so that either element can be recovered independently as far as is possible.