Validation error
When I just completed a new full backup, it reported success. However when I tried to run a validation, I received the error shown on the attached message. I using True Image Home 2009
I'm using an external HD for the archives. When running chkdsk (3 different times), it stops after check #4. Have left it on for 15 hours, but nothing further happens. Have run "cleanup" and "defrag" on that disk with no problems. Any idea what could be causing this? Many thanks.
I believe that step is verifying file data and it is having a problem obviously.
Do you have any other indications of a problem such as excessive "chattering" from the disk, usually caused by the disk doing retry's in order to get good data from a sector.
Can you run a disk diagnostic from the drive manufacturer on the drive?
I'm unable to run a diagnostic; however have not heard nor seen any "chattering" or unknown noises. I tried scan disk and it stopped at the same spot (4). I also booted up with the IT Rescue disk and tried to Validate from there; got allmost to the finish and then got the error message again. I'm going to go ahead and reformat that external drive, run scandisk again and see if I still have the problems. That will lose the previous backups, but I don't trust them anyway. If that won't help, guess I'll go back to version 11. Had no trouble with that version.
You could try and copy the backups to the internal drive. If there is a bad file, the copy process may choke on it.
If you format, don't do the quick format so the format will do a surface scan of the disk.
Other thing to try is to make an image but store it on the internal drive. If you only have one partition, TI will still create the image after warning you about it (as long as there is enough free space on the drive). You can then try and validate the image on the internal drive. If it works, then it points to the external as the possible problem.
I hadn't realized that you had used TI11 without problems but it could just be a coincidence that the validation failures have occurred with TI2009.
I finally gave up on TI 12 and went back to TI 11. No problems with verification either on external drive or doing bu and verify onto the hard disk. For some reason, TI 12 just wouldn't work for me, continually got "corupted archive" when trying to verify. It seems 12 must be like the "Vista" upgrade from MS; good idea, but poor results.
Very strange but strange things happen. There is still the issue of why chkdsk won't run to completion on the external HD which means one can speculate that perhaps TI2009 is doing something a little differently from TI11 and the problem with the external HD is tripping it up. Maybe!
Trying to create and validate the archive on the internal HD would remove the external HD from the equation.
Other thing that could be tried if you feel like it is to create the archive and validate it with the TI2009 rescue CD. This takes any Windows issues and the TI snapapi.dll driver out of the picture and you don't have to reinstall TI2009 to do it. You could also do the internal HD test above this way.
Anyway, you have a backup mechanism that appears to work.
I too have validation errors using TI 11 Home.
When validating an image, sometimes it validates okay, sometimes it gives a validation error for that same image.
I find here many reports of people having this in various versions of TI: 11, 2009, 2010...
It can't be that all these problems are caused by hardware errors. Especially since the pc does not give any problems when working with it normally.
I strongly believe that the TI validation routine (throughout the various TI versions) is 'less than optimal' (not to say 'buggy'...).... How hard can it be to write a solid validation routine that is reliable ...?
Kind regards
Eddy
You can add the TI ... 6, 7,8,9,10 to the list of people reporting validation issues. Then you can look at other imaging products and see the same thing.
Yes, the PC appears to be fine with normal use but in normal use how many times is it dealing with a multi-GB file that has very stringent error checking, not a the disk connector but after it is read into RAM. PC hardware does virtually no error checking internally other than the CRC at the disk.
The validation routine is only a fancy checksum calculator.
If there is a bug it is a hardware dependent one because too many people don't have any trouble valdiating archives at all (although there may have been 1 fix, IIRC, for a validation problem on some machines). I've used TI since version 9 on several machines and the validation worked on every one of them. I have had 2 valdidation failures, one caused by bad SATA cables (and the machine appeared to work fine although Windows did mark an entry in the Event Log but if you didn't look there you would never know it) and the failure of a previously validated archive which went bad because of HD sectors failing.
The other cause of validation errors, when the Windows validation works, is inadequate Linux drivers for the hardware on the TI rescue CD.
There is no doubt that the TI valdiation puts more of a "strain" on the PC than normal activity.
@SeekForEver, (feels awkward calling someone that.. :-) )
I'm not saying that you are wrong. In fact, I've been using TI since version 7 (on various pc's), but in the beginning I didn't use image validation at all, so I can't tell when this became a problem.
Now as to the fact of file validation in general. Indeed, I suppose what they do is taking a chunk of the image file, calculate the checksum (MD5, CRC32, SHA-1, or whatever) and compare that checksum (or hash value if you like) to the value stored in the file itself.
Doing so, basically requires a sequence of 3 operations:
1 - fetching the chunk of bytes from the (image) file,
2 - calculating the checksum/hash value,
3 - comparing the calculated checksum with the checksum stored inside the chunk of bytes under investigation.
Now where can this go wrong:
1 - fetching the bytes from disk:
a - the image is bad to begin with (bad disk sector or whatever)
b - drive cabling is bad
2 - calculating checksum:
a - memory is bad
b - software routine to calculate checksum has bugs
3 - comparing calculated checksum with stored one:
a - if this goes wrong, it is likely a combination of the above. Either fetched checksum is bad due to disk error,
or software has bugs.
If we disregard software bugs and focus on hardware as the culprit, we can summarise:
- bad disk
- bad cabling or
- bad memory
If all the reported validation errors would mean that the pc in question was suffering from one or more of the above mentioned illnesses, people would notice difficulties while running their other day-to-day software.
If a disk is bad, sooner or later one of your other (non-imaging) applications would suffer from this, If memory is bad, sooner or later one of your other (non-imaging) applications would suffer from this.
I can't believe that, while working on a faulty pc, none of your other applications (that you are running all day long) is bothered by this, but TI xx happens to encounter this problem and it fails over it ...
Sounds a bit ... odd to me. Since I feel that checksum validation is such a simple routine, and it certainly is used under the hood by many programs, and they do not seem to report errors as much as TI.
To me that only leaves one possibility open: software error, perhaps in combination with certain hardware, I do not rule that out. But all hardware errors ??
Naaaahhh ....
Speaking of which .. I will run some tests, using 3rd party software to do checksum calculations on image files, see if the checksum comes out different on different runs.
Anyway, 'SeekForEver', don't take this personally, I highly value your contribution to these forums. 2 people know more than one !
Kind regards
Eddy
PS. I have been running memory checks for the last few hours using Memtest86+ and not a single bit that failed so far ..
Kind regards
Eddy
...
If we disregard software bugs and focus on hardware as the culprit, we can summarise:
- bad disk
- bad cabling or
- bad memory....
I can't believe that, while working on a faulty pc, none of your other applications (that you are running all day long) is bothered by this, but TI xx happens to encounter this problem and it fails over it ...
Sounds a bit ... odd to me. Since I feel that checksum validation is such a simple routine, and it certainly is used under the hood by many programs, and they do not seem to report errors as much as TI.To me that only leaves one possibility open: software error, perhaps in combination with certain hardware, I do not rule that out. But all hardware errors ??
...
Eddy
Based on causes uncovered by previous users, you can add to the hardware list :
Bad motherboard. This component obviously is part of the route into RAM and contains cache, cache controller, disk controller, along with everything else.
Bad CPU. One person had 2 identical new systems. One failed, the other didn't. After much testing he swapped the CPUs and the fault moved with it.
Power supply, low voltages or excessive noise.
I agree that it is somewhat difficult to see why the PC seems to be fine and fails with at TI valdiate. However, it could may well be a case of a very, very large amount of data at high-speed that is being very carefully checked. I have had Memtest86+ run for several hours before errors were reported. People have run Memtest86+ and never had it report an error but found it by swapping out RAM sticks. A diagnostic isn't real life - consider all the disk activity and other things going on when you are doing a validate that isn't taking place with the memory diagnostic.
As a comment, I've found more marginal RAM problems by Memtest86+/s random data tests than with straight bit-walks and fixed patterns. I find this a little surprising since this used to be a characteristic of old magnet-core memory systems due to the routing of data and sense lines through the cores. But cross-talk at some level always exists no matter what the electronic system.
It is also known that TI can fail on over-clocked machines or machines with aggressive memory timings and the recommendation is to run in "standard mode".
We can get into a discussion of just how TI sets up its validation and perhaps it is marginal on certain chipsets but since I didn't program it, I don't know how they are accessing the hardware at the driver level. But OTOH, one would suspect that there would be problems reported by all users of a certain chipset if this were the case.
You said that your archives validate sometimes but not always - does this mean the same archive validates and fails? Or some validate and some don't.
Does the validation success/failure happen identically with both the Windows version and the CD version?
You said that your archives validate sometimes but not always - does this mean the same archive validates and fails? Or some validate and some don't....
Does the validation success/failure happen identically with both the Windows version and the CD version?
The same archive sometimes validates okay, validating again it can fail, and validating another time it may pass again. Sometimes almost all of the validations I try fail and sometimes they almost all pass. There really is no pattern.
The same happens when using the CD (BartPE) version. I can't use the Acronis bootable media CD because that version does not see any drive.
Hi,
I'm having the same Problems with Acronis True Image 2009.
I'm using TI for a long time ( starting with TI 7 ), and never had much problems with the software.
Now with TI2009 we have a lot of problems
* Backup finished without Errors, but Validation check fails
* Backups sometimes just quit during Backup-Process ( in the Rescue-System), without finishing, sometimes with notice : Backup failed, but otherwise telling nothing, just rebooting.
* ...
Hopefully there will be an update soon...
I also don't think it's a hardware-problem, I have the same problems on different hardware, and I don't think that all our newly bought hardware is faulty...
I would recommend that those using an external hard drives as the destination drive, to backup the image file to another internal hard drive/partition and then validate it.
This of course would be just for testing, as there were some issues some years ago with some USB to sata/ide "bridges" corrupting data.
You could then copy or move the data to your external hard drive and re validate the archive, just to see if the external chipset is causing a problem.
I create MD5 values for all my images, so if they are say split into smaller files I can use a program such as Checksum (http://corz.org/windows/software/checksum/) and create MD5's quickly for as many files as i like, then when i move them to an external hard drive of cd, dvd usb stick etc, I get Checksum to quickly verify them again.
This is also a good confidence test when archiving any data, as I create MD5's for all of my files in my software "library" I can easily check file integrity, after it's been moved, compressed or manipulated in any way to see if anything has changed (or not).
Vorlon,
I already make my images on a separate internal disk.
I have my Windows XP running on one internal disk and I create the image on another fysical harddisk.
I then indeed make a copy of the image to an external (USB) harddisk, but the image validation I described above is done on the original images on the internal disk.
I was planning to write me a small test program that sort of imitates the validation procedure of TI.
Of course, I do not know exactly how TI works internally, but I was thinking of letting my test program fetch chunks of the (large) image file, calculate a checksum, then fetch the next chunk, combine this checksum with the previous one, etc.
If I run this test several times on the same image file, the resulting checksum should always be the same. If not, there is indeed something wrong with my hardware.
Vorlon,
I already make my images on a separate internal disk.
I have my Windows XP running on one internal disk and I create the image on another fysical harddisk.
I then indeed make a copy of the image to an external (USB) harddisk, but the image validation I described above is done on the original images on the internal disk.I was planning to write me a small test program that sort of imitates the validation procedure of TI.
Of course, I do not know exactly how TI works internally, but I was thinking of letting my test program fetch chunks of the (large) image file, calculate a checksum, then fetch the next chunk, combine this checksum with the previous one, etc.
If I run this test several times on the same image file, the resulting checksum should always be the same. If not, there is indeed something wrong with my hardware.
It could be hardware related, so I would recommend burning the Memtest 4.0 http://www.memtest.org/ to disk and running, or if you have Vista using the built in memory Diagnostics on the Extended test (does take hours to complete though with say 4GB of ram on 2.67Ghz Dual Core CPU).
You could Create a Test Partition, or use one of your existing partitions with say around 4GB of data (to save time, but be sufficiently large enough for test), use Checksum (and the root switch):-
http://corz.org/windows/software/checksum/
so that there is just one *.hash file in the root of the drive and calculate MD5's for all your files on that drive.
Then if after creating an archive with True Image of that partition validation fails, restore it somewhere and then use Checksum to see if the files are intact or not, or what's likely failing.
Other than that I would check my drives with checkdisk and the following "switches".
x = your drive letter for checking
Command Prompt
chkdsk x: /r /v
Also have you checked your Drives SMART status? Hdsentinel (http://www.hdsentinel.com/) is a good thorough program for monitoring and checking drives, external drives too.
Vorlon,
I already did a MemTest86+ 4.0 with all the available tests. No problems at that time.
I also did a diskcheck from within Windows. No problems too.
Of course, that does not mean that there couldn't a problem somewhere, I know.
Thanks for your other tips. I'll see what I can do.
PS. I am using Windows XP Pro SP3
If you want to check data integrity by copying data from one partition to another and comparing, this batch file is ideal:-
Copy the following into notepad and save the file as something like testdata.bat:-
@echo off
echo checking data
echo [press ctrl+c to terminate script]
:Loopcopy %1 %2 >nul
fc /b %1 %2 > nul
if ERRORLEVEL 1 GOTO FailGOTO Loop
:Fail
echo sorry, data corrupted...
Then open up the Dos window/command Prompt and navigate to where the testdata.bat file is that you've just created and enter your source file location and destination on the command line.
So for instance:-
Source file can be any file you like, so for instance take a large file say 2GB+ and name it something like testfile.dat.
Then the command line depending on your source and destination drives are would look something like:
c:\testdata.bat d:\testfile.dat h:\testfile.dat
I've used this batch file and it does the job well by first copying the data from the source file to the destination and then comparing them using the Dos Fc.exe utility which i assume is available on XP as it is on vista. It then compares files byte by byte, copies again and continues to repeat the excercise until there is an error or you stop the batch file.
Original discussion on it here:-
http://bigacid.wordpress.com/2008/12/08/jm20337-read-data-corruption-so…
In my book validating images is a waste of time. Validations may raise the level of confidence that a restore will probably work but it is not an absolute guarantee of sucess.
The method I use which really does work 100% is to restore images to swapped over main hard drives. There is no risk at all to the source main hard drive because it is safely outside the computer when the restore is run to the replacement hard drive.
In the very rare event that an image cannot complete a restoration and the program reports the image is corrupt it is a simple matter to swap back to the previous hard drive and start over.
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.
Infrequent and sporadic hardware faults can take a bit of finding but systematic and thorough investigation pins them down eventually.
Sounds like a good idea, but not sure what you mean by "swapped over main hard drives"
I don't really agree with Xpilot that it is a waste of time but it certainly isn't necessary using his method which does indeed provide a higher level of confidence concering a restore because it has already be done.
Xpilot has disk racks/caddies/trays and he makes an image of his HD onto a suitable location. He then immediately takes out his current system drive and restores the image he just made to it and then that disk becomes the "in-service" disk until he does his next image.
If the process fails to restore he knows about it right away and can fix the problem and do it again.
You can't argue that this doesn't give a higher level of confidence. It is similar to the benefit you would get with cloning and putting the clone into service as a backup method without one of the major disadvantages of cloning - you can only have one clone on a HD.
Vorlon,
I am using the checksum tool that you mentioned now and I am currently also running the DOS copy-and-compare batch file. No problems reported now but I will keep checking.
Thanks for all your input (and everyone else too).
As I mentioned in one of my previous posts here, I wrote me a little test program to (more or less) simulate the behaviour of the TI validation test.
Since TI validation can already detect a checksum error before finishing reading the file, I thought I would do the same in my testprogram:
My testprogram takes chunks of bytes of the file which is tested. Of every chunk a checksum is taken, that checksum is concatenated with the previous checksum, forming the new 'current checksum'. Then the next chunk of bytes is read, checksum is taken, concatenated with the previous checksum, etc.
When the total file is read, a resulting checksum is displayed. This test is done a number of times in a row (number can be specified at program start). Naturally, if all goes well, all the displayed checksums should be the same.
This testprogram uses 2 threads: one to fetch the data and one to calculate the checksums.
This method of calculating a checksum is no better or worse than any 'regular' way of calculating a checksum. The only intention of this testprogram is to try to simulate the stress that is put on your hardware by the Acronis True Image image validation procedure.
In other words: if there is something seriously wrong with your hardware, it should show up in this test program.
My system is under test now .... :-)
It appears from your comments that you are nowledgeable! So, I do not have an addition to your comments; I have a question. Acronis support has not responded nor has Perfect Disk support.
I have followed all suggestions from Acronis support, Perfect Disk support and comments posted here and the validation process fails. This failure is persistent when any RAXCO software (Perfect Disk)is installed on my ThinkPad W700, 8gb memory, Vista Ultimate 64 bit laptop. If I remove Perfect Disk, restart my computer twice, the validation process is successful. Therefore, I conclude that the validation error is created as a result of software conflict between Acronis TIH 2010 build 6053 and Perfect Disk 10 Pro build 124.
Do you have any suggestions?
Thankyou in advance for your consideration!
I am not familiar with Perfect Disk, but it would seem that your conclusion about a software conflict would be correct.
What exactly does Perfect Disk do; is it a necessity for operation of your computer? If not, try disabling it before you run the backup and the verify.
Thank you for sharing your thoughts.
Perfect Disk is a third party defrag program that provides a number of defrag options including all system files and the MFT. The system and MFT is generally completed at boot time. I use this program because I am obsessive about perfection which I relentlessly pursue. Yes, I am human with all frailities. Like Mark Twain said, "I am human, and I regret it." So do I.
However, my previous comment was inaccurate. I had not tried backing up to an internal system disk; with great curiosity I must report that doing so was successful.
Thank you.
Another way of taking Perfect Disk and all Windows stuff out of the equation is by booting the TI rescue CD and doing a validate with it. It is Linux and is a completely different driver environment.
Note that being able to validate from the rescue CD is actually more important than Windows since this is the environment TI normally uses to do a restore of the active partition - even if you start it within Windows.