Validation or verification?

Am I right in thinking that TI 11's validation of a backup validates the internal consistency of the backup file/s - as opposed to verifying that the backup is a true copy of the original files by doing a side-by-side comparison?

 

Yes. TI doesn't compare the image to the source.

 

Yes you are right, the checking process involves checksum comparisons, not data comparisons, although somewhat contentiously perhaps, I view the process as verification not validation.

The main thing for me, is that Acronis should stick to one term and not call one process by two different names.

F.

 

When ATI beates a backup, it creates a check sum every so often and embeds the checksum in the file. When you validate, it reads the file, recomputes the checksums and if anything doesn't jive, declares invalid. So prob could be wrong bytes written (which means the file is no good), wrong bytes read (which could mean the file is fine) or both. Also note that you miht be able to validate a file when you do that from within windows but not be able to when you use the bootcd, so be sure to check.

 

Tnks MudCrab, foghorne and shieber. Now if only Acronis would implement true (file versus file) verification and allow it to be run from within the bootable recovery (Linux) environment as well as the normal Win one, I could rest easy at night. After all, doing a test recovery to a spare hard disk and then successfully booting Win only shows that a small part of the restored image was OK.

I normally back up to a WD USB big disk, but for offsite storage I still make occasional DR backups to DVD-RAM using Backup MyPC* V6 since is does a true verification (and I don't trust DVDs!). Come on Acronis - you implement exotic features at the expense of my peace of mind!



* - Connor / Seagate / Veritas / Stomp / Roxio / ... and distributed by Orlogix from Ireland. Who owns it now is anyone's guess. Perhaps Orlogix do.

 

I assume that you are talking about OS comparison rather than data ? with data there is no problem to make a back up image. forget all about verification.
just use a program like beyond compare 2 to compare the original data with a mounted version of the data image.

comparing an OS image with the original - which I assume is what you want - is not so easy. Using Beyond Compare it is possible to verify that almost all files are the same but there will always be some temp files that change simply as a result of making the image or making the comparison.

To make a comparison you would have to make an image without making any changes to the system and then find a way to compare both the original system and the image from outside ie using another computer.

Once I found out that Acronis made good images with boring regularity I gave up being concerned - and wasted no further time on verification.

 

Thanks Longview. I wanted to use (as far as possible) the bootable recovery system's Linux drivers to compare the original with what was backed up. This avoids the need for a spare internal disk and tests that the backup copy is readable by (mostly) the same code which would be used to do a real restore.

It doesn't of course test that the Linux drivers would then write everything correctly during a restore but at least we get round the problem of a normal (Windows) backup validation saying 'all OK', but any later DR image restore made using the bootable Linux version saying 'Sorry - archive corrupt' because of incompatabilities between the drivers or between driver and disk.

The ideal may be to do a standalone compare between original and restored version (i.e. a version restored to a bootable environment such as a spare internal disk).

But the trouble for me with all operations involving a standalone boot is that I cannot start a backup job running overnight and have it completed automatically (with credible verification) the morning afterwards. C'est la vie...

 

I won't argue that a compare with a static disk wouldn't be a nice feature. However, if your Linux CD can reconstruct the 4000 checksums per gigabyte when doing a validate, it is a pretty darn good indication the archive file is being read properly. Weakness in this method is that an improper reading of the disk initially when the archive was created will not be discovered but I don't really get the impression this is a common fault especially if you run chkdsk from time to ensure the disk structure is in good shape.

IMO, once you confirm that the Linux environment works on your machine, ideally by a test restore, or the next best thing a validate using the linux CD, then you can have faith in the Windows validate - in effect, you have verified that the linux stuff works with your hardware. Many of the problems are caused by users putting faith in a good result from a Windows validate only and then when a restore is needed having to use the Linux environment which has never been tested and again, IMO, is a major cause of unhappiness for many users.

 

Many of the problems are caused by users putting faith in a good result from a Windows validate only and then when a restore is needed having to use the Linux environment which has never been tested and again, IMO, is a major cause of unhappiness for many users.

Tnks seekforever, spot on in my opinion. And I guess the trick is to have a spare internal disk (to test-restore to) which is as similar as possible to the operational disk which has been backed up (e.g. no mixing PATA and SATAII). Once the standalone restore process is more or less proven to work (e.g. if the restored disk is bootable - although this does not guarantee perfection), the disk can be whipped out again.

 

My experience of programs of this type has been that either they work or they don't. This means that the first image is the risky one. After that, provided you keep a series of images, there should be no problem. Having started with Acronis 6 I can only remember one restore problem and that was caused by a bad usb cable. I changed the cable and the so called "bad" image restored no problem.

 

But surely it is a waste of time and effort to whip it out again. I just leave the freshly restored disk in place and carry on working until I decide to refresh the old disk from a new image. As the old stagers will already know I actually use a rotation of three main drives.

It may not have been noticed that the checksums, recorded when an image is created, are checked when the image is restored to a drive.
This ensures the integrity of the restored drive beyond all reasonable doubt.
I have not wasted any effort on running validations as an additional check because it is not needed when the backup strategy ensures that the current hard drive is not overwritten until it comes round to its next turn in the cycle.

Xpilot


What may not have been realised is that the check sums, which are recorded when an image is made, are read and checked as part of the restore process.