Discussion in 'Acronis True Image Product Line' started by gww528, Nov 20, 2008.
Using TI 2009, how necessary is it to Validate the backups?
It's mostly a matter of personal comfort. The only true validation is to perform a successful restore. The validation does NOT compare the contents of the disk to the contents of the backup. It simply compares the stored checksums against freshly computed checksums. A "valid" backup may not restore, and an "invalid" may well restore.
Make sure you can enter the restore process both from Windows and from the boot disk, and that both can see the drive you would restore and the restore file on whatever drive it is. If it can, you are about a valid as you can be without a restore.
You should, restore your disk, probably safest with a second disk, and see if it will boot before you trust to your backups.
Many folks validate every time, but in the end, it only makes them feel good, it doesn't prove anything.
If a bad checksum is encountered during a restore the archive will be declared corrupt and the restoration will be terminated. The partition being restored will be left as unallocated space on the disk.
Not quite. You can increase the odds of a good restore a lot by doing a validate with the rescue CD. The rescue environment is Linux and by doing the validate you are demonstrating the Linux drivers and program are capable of properly reading the backup media and re-creating the checksums in RAM. Not doing a validation test using the rescue CD is where many users come unstuck. They think that the Windows validation proves the archive is readable and can be restored but Windows isn't used when the active partition is part of the restoration.
Definitely the best test.
Once you have demonstrated the Linux rescue environment works well then a Windows validate will show that the archive checksums can be re-created in RAM. In this regard, it does show that the archive is not using any bad sectors on the storage media and it also shows that the RAM is still OK. Bad sectors, faulty USB subsystems and bad RAM can be picked up by the failure of the validation. Granted hardware failures are not frequent but they do happen.
validation is a waste of time. I never do them.
As long as your backup completes with no errors, it should be good. To check them, I just mount the image and browse through the folders in the backup.
In my case I've done enough backups and restores and have yet to encountered a corrupt image. If I had encountered even one corrupt image than I might have different views. True image might have "alot" of problems but producing corrupt images isn't one of them. The only time I read of corrupt backups are when using DVD's as a backup media (and that is cause by using low quality blank dvd's)
I agree. Validation is more to check your hardware than to confirm the image is OK. If you keep images long term they should be validated at "regular" intervals. This can pick up bad RAM before you learn the hard way. We have read several
threads where the image wasn't validated prior to restoring and this happened...
What if this was the only backup image ?
A Validation will never tell you that ATI will be able to restore on your hardware.The first time you do a restore, that's when you test whether your backup program can restore on your hardware. You don't want that test to be when you actually neeed to restore your drive because your hdisk failed. Better to find out before any hardisk fails.
After that, if ATI works restores on your hardware, validation is just an ersatz indicator of file intergrity as other have descdribed above and generally not useful or necessary. If backing up to or from a new drive, it can be an idicatior of whether ATI works properly with the drive.
The one thing to remember is that regular PCs do not check anything when data is written. A disk write will write in the data area of a bad sector and nobody will know anything about it until comes the time to read the sector. RAM data in or out is not checked and will only become obvious if the bad data causes the program to fail in some manner - such as calculating a checksum.
My bad SATA cable experience only showed up on Validates and a Restore, never on writing the archive.
The answer to Brian K's question about only having one image is the technical term - screwed! Always keep as many as possible on hand.
Thank you for choosing Acronis Disk Backup Software.
Please accept our apologies for the delay with the response.
All recommendation given are correct.
We are always strongly recommend to validate backups prior restore, because corrupted backup will not restore and may cause issues.
The most common reasons of backup corruption are:
1. Corrupted RAM module
2. Bad sectors on your hard drive
3. Remote backup storages
There are several ways to overcome backup corruption:
1. Try to validate it from Acronis Bootable CD (as correctly mentioned earlier)
2. Copy it to internal drive from network storage
3. Try to mount an image (for partition\hard drive images only).
Unfortunately, some corrupted backup issues means data loss. In such cases, the goal is to investigate why the image was corrupted to prevent same situation in the future.
If all suggested workarounds does not help, please create Acronis Report and Windows System Information as it is described in Acronis Help Post. Then submit a request for technical support. Attach all the collected files and information to your request along with the step-by-step description of the actions taken before the problem appears and the link to this thread. To expedite the resolution we recommend you to use our Live Chat service after that. We will do our best to investigate the issue and provide you with a solution.
One thing a validation will tell yu is whether ATI can successfully read the file. If you can't validate, you can't restore. Therefore, it is prudent to validate a backup before restoring to ensure that ATI can use the file to restore -- otherwise, you could end up with the ATI deleting the partitions on your restore target hdisk but then be able to create and write the partitions from the backup to your target hdisk. For many situations, that is not an issue, the targethas nothing any longer useful on it anyway. But if it does, then you would want to validate jsut before restoring.
As a general practice after creating a backup, not so useful, as has been described above.
Separate names with a comma.