Corrupt/Can't Verify Corrupt Archives: Let's uncover the problem!

I truly cannot believe the state of denial evident in the last several posts.

I also find it infuriating -- here as well as other forums -- when people post that THEY don't have the problem. At the risk of being too sarcastic, let me say, "Well, good for you." Whether intended or not, saying that YOU don't have a problem implies that those who DO have the problem must somehow be doing something wrong and that it is their fault. While there is plenty of "cockpit error" when we all deal with computers, and therefore many cases where the person posting is doing something wrong, you have to understand that when you have dozens of people -- not only in this thread, but in many other threads in this forum and also elsewhere on the Internet -- who DO have problems validating, then you have to, as I already said, be in some sort of existential state of denial not to understand that a problem really does exist.

Finally, I really have to scratch my head over the logic (illogic?) of this statement:

Huh? By that logic, then ALL posts from a year ago should have 17,373 views and 299 posts. Of course they don't. The reason this has twenty times the number of views of any other thread on page one of the forum, and probably one hundred times the number of views of an average thread is -- does this sound too far fetched? -- because lots of people are having the validation problem and are eager to find out how to work around it or solve it.

I honestly don't see the point in denying this widespread problem, unless you work for Acronis and want to make potential customers think that there isn't a problem.

For those wishing to research this further to see what else is being said about corrupt validation in Acronis Trueimage, you can click on this Google search and have a look around the Internet:

Google Trueimage Corrupt Validation Search

I am sure that not all of the 9,000+ hits relate exactly to this problem, but as of the moment that I posted this, half of the links on the first page of the Google search to point to posts in places outside this forum where people (not me) are reporting exactly this problem.

 

I've had corrupt images on my Seagate FreeAgent Pro using TI11, but since focussing instead on backing-up to an Internal drive have had no problems. So I think there is something inherently glitchy about USB drivers. And maybe my FAP firmware as well.

So a workaround for you might be to continue to make your backups internally, then transfer them to your external (I know, ugly & time-consuming).

Sorry I haven't read everything here, but have you tried making a PEbuilder version--maybe it will work better for you (I intend to myself but just haven't gotten round to it).

 

It isn't just TI that sometimes chokes on USB drives. I use SyncBack and have found that sometimes the copy a large file (in the GB region) will not verify using SyncBacks's source comparison method. IIRC, but I'm not sure, it was on a MyBook external HD.

I don't consider your workaround to be ugly and time-consuming; it is the way I do all my images. It is fast, no plugging up and plugging in an external. Images made to a second HD are relatively secure, much more than on a SZ created on the drive you have backed up . I then copy selected images to an external for extra security. Using an internal is fast so you are more inclined to make an image before for you test something and you can then quickly restore the image after testing. I also operate the same way on a notebook with only 1 HD by creating the archive in a second partition.

 

This thread has been running for two or three years.
Isn't it about time Acronis got to grips with the USB problem?
It just isn't good enough to have a backup that you haven't confidence in, and as I have just found you can't restore from.
That's a lot of work lost.

 

My point was that other programs may also have troubles with some USB drives as I found out. Not necessarily the drive itself but how the drive's chipset and that on the MB communicate most likely.

I would hazard a guess that you kept making backups assuming you could recover from them and then found that wasn't the case. No backup program on earth, not just TI, should ever be trusted to be adequate until some test restorations have been done successfully. You can't wait until you have a real problem to see if the backup works properly.

IMO, TI should make this point much more obvious than it does and it should also be more proactive in stating a Windows Validate is of little value until you have demonstrated you can validate and restore with the Linux rescue environment.

 

Hi All,

Best solution is to take the away the need to use the Bootable Rescue CD. How? Redo your System completely.

• Create a small Drive C: which is the Boot Drive, which is used for two operating systems. Format it using the Fat32 File System.
• Install Windows XP or Vista onto Drive D:
• Install Windows XP or Vista onto Drive F:
• Use Drive E: as your My Documents partitions. Both operating systems can indeed access the same My Documents partition.
• If the Hard Drive is large enough, one can use a single partition for Drive Images.

You don't want to hide the operating systems from each other. There is nothing written that the operating system must be Drive C:

Note: When installing Windows Vista Ultimate RC 2 in the past from the DVD, it installs as Drive C:, even though physically it was installed on Partition G: Both Windows XP Home Edition and Windows Vista Ultimate RC 2 did access the same My Documents Folder without problems in a Dual-Boot scenerio.

Comments?

 

Yes, this will work but there is one big problem with a dual-boot setup like you have described. Every time that you boot into Windows XP it will destroy all of the System Restore points on the Vista partition. Details are given in KB926185. Generally you will have fewer problems with a dual-boot setup if the operating systems are isolated from each other. You can still share a common partition for storing documents, and TrueImage can still back up or restore a hidden partition, so all things considered, isolated systems are better and easier to maintain.

 

Hi Mark,

That isn't a problem, if you don't use System Restore in the first place. Just do a Partition Image after adding a new program that you want or Weekly. Also if you want to use System Restore, you can, but just turn off System Restore for the Vista Partition and in Vista Turn off for the XP partition.

I have System Restore turned off and just use Acronis. Works great.

 

I discovered something interesting about Flash Drives the other day, and have yet to ascertain whether the same is true of USB hard drive enclosures.

Not all flash drives report themselves as drives, some report themselves as hubs. I only found this as I was about to start coding for some embedded USB projects, and I discovered my test Stick, was being discarded due to it saying it was a hub device. Further research revealed that this isn't such a problem with MS Windows, but some Linux kernels and drivers choke when this happens. Might explain why some flash drives are TI bootable and some USB drives may or may not be recognised in the rescue environment.

Colin

 

Indeed not and is in fact a liability. Even worse is that you can have a corrupt file which actually validates positively which I didn't realise and therefore I will almost certainly abandon any further use of this program unless this particular problem has been solved since you first started this admirable thread.

My problem is that I can't get any backups to validate!
In fact, having removed v11, I then couldn't either re-install it or install v10 but that is another documented problem which I didn't solve! So last night I installed a trial version of 2009 which did install, but the validation problem continues. But it also occurs using Ghost v9 so it is not specific to True Image.

So for the moment I have delved into my past and written an xcopy batch file.

But are people still having problems restoring from validated backups?

Chris

PS Why on earth don't backup programs default to verifying/validating backups?

 

Validation with TI and any program that does live imaging where the source is no longer in its original form during/after the backup is done by reading the archive and reconstructing checksums that were included in the archive. TI writes 4000 checksums per gigabyte of data and one bit wrong in any one of them causes the archive to be declared corrupt so it is a pretty stringent test. Also, the archive data has to be good when it is read into and stored in RAM since that is where the checksum calculation is performed so just looking good at the HD connector is not enough.

This means, even though johnmeyer thinks it is a red-herring, that your RAM has to be rock solid. TI probably puts more of a strain on the disk subsystem and RAM than most, if not all, applications because of the high throughput and the vast amount of data. Other apps can use bad RAM and depending on the location of the RAM failure, it won't even be noticed since regular PCs do not use parity RAM or ECC RAM and the data is not checked going into or going out of RAM - it is just assumed that it always works.

So one of the first things to do, and it is also fairly easy, is to check your RAM. In your case where more than just TI fails it is an even more likely cause of the problem. Other things can be anything in the disk subsystem as well. My only failure running TI was a marginal SATA disk cable which incidently did not show up when running regular apps. To check your RAM, download free memtest86+ from www.memtest.org , the current version is 2.01. Let it run for several passes, overnight is best. A memory diagnostic isn't exactly the same as normal system activity but it is easy to try.

To rule out some disk problems, run chkdsk X: /r on all your partitions, particularly the one you are storing the archive in. The /r option does the same as /f but also includes a surface scan to ensure all sectors can be read properly. Replace the X in the command with the drive letter of the partition being tested.

You can also check your voltages. Voltmeter is great but modern machines usually display them in BIOS.

Note that anything at all that will compromise the data integrity will cause an archive corrupt error. This literally means anything in the PC from the drives to the power supply to the motherboard. USB drive chipsets that don't play nice with the motherboard chipset can be a problem but in recent time, this seems to be less of an issue than it once was - especially for very large files like archives. Yes, a poor fit of the backup software to your system can cause it too.

The least problematic method for storing an archive is to store it to an internal HD. This can be a second partition on the main HD, a second physical HD, or you can even store it on the C drive. TI will warn you that you can't restore C from an archive stored on C but let it write it anyway since you want to test the validation.

Your PC should not be overclocked and your memory should not be using aggressive timings.

Important
One more thing, and this is very important because it is where so many of the "I validated and it won't restore" users come unstuck. TI's rescue/restore environment is Linux not Windows. IMO, this is a TI Achilles Heel because the Linux drivers may not be a good fit for your system which can cause all sorts of problems. There is no point in validating in Windows and then saying all is well because when you do the restore of the active partition, typically C, Linux, not Windows is running. You must ensure the rescue environment works on your PC before disaster strikes and the best way is to do a test restore to a spare HD in case it fails. (Since you can't validate even in Windows presumably, you aren't at this stage yet.)

If you can't/don't want to test restore to a spare HD, then the next best thing is:
Boot up the Linux rescue CD.
Locate your archive and Validate it.
If that works, then go through the Restore Wizard up to the last screen that asks you to click Proceed but CANCEL out so you do not proceed with the restore.

Once you are convinced the Linux rescue environment works on your PC then you can have faith in the Windows Validation procedure.

 

I appreciate your reply!

Interestingly there was no problem at all until a few weeks ago. In fact I was performing a daily incremental onto a second sata drive with no problems. Now however, the problem occurs writing to that second sata drive and an internal scsi and an external. It also occured when running from the boot disk.
Since my last post earlier this evening I have succeeded with two small (7gb) backups onto the second sata drive.
I'll start with the memory test tonight!
Thanks.

Chris

 

Please let us know the results of your memory test.

 

I can't believe folks are still posting to this thread with over 300 messages in it. Methnks it has wandered hopelessly. Maybe time to shift the last few messages to a new thread and close this overloaded puppy down.

 

I've read only some posts in this thread, in those I have read there is no mention of what may be a problem - I don't know, defragmantation of the image.

Yesterday for the first time I had a corrupt file, it just dawned on me to check my images partition to see if is defragmented, yes, every file is fragmented. I'm going to transfer them to another drive and format that partition that had the images, then I'll copy them back.

Nothing in my PC has been changed.

BTW, there are SATA signal cables out there with latches that hold the cable more securely than the ordinary cables.

 

Yep. Those SATA cables with the clip are the revised standard; the revision made by the SATA team when it was learned that the original standard was, well, kind of crappy.

 

Re: Memory test

Well I started Memtest86 and was immediately faced with a red screen full of errors. So thanks for the advice

I have two 1Gb sticks of Crucial Ballistix running in a very modest environment which were given to me a few months ago (before the problems started). I have replaced them with my original ones and successfully completed a full backup from within windows.

 

Re: Memory test

Glad you quickly found the problem.

 

Had an interesting experience that may shed some light on the "Can't Verify" situation. I made a backup of a machine onto a USB Drive, then tried to validate it on my main desktop system. It failed with the "normal" message (title of this forum!).

As I usually copy these images to an "archive" disk, I tried that with the "corrupt" image. It would not copy in Windows. Said I did not have permission. I have Win XP Pro with Simple File Sharing checked. After I turned off Simple File Sharing and manually set the permissions to allow Windows access to the image file (and then turned Simple File Sharing back on!), it Validated correctly!

Don't know how many of these errors are due to Windows Permissions (a very opaque subject on its own!), but those that are due to Permissions are just getting a misleading error message from TI. Wouldn't it be nice it TI could recognize this and give a better message.

Any of this possible in other the cases reported of Validation errors (and also of "can't restore" errors when it successfully validated earlier on another drive)?

 

Did you create the archive using the TI rescue CD or in Windows? If the rescue CD was it in TI Full or TI Safe mode? I used to have this problem with XP using an older copy of Drive Image. The program ran as a real DOS program so when it created the archive files the permissions were wrong since it knew nothing about permissions. The solution was the same as yours.

This was the main reason I abandoned my faithful PowerQuest Drive Image and got into TI.

 

Well, I tried this, but it didn't work. What I have found in the long time that this problem has been discussed (and not yet fixed) is that it is tough to reproduce. I can sometimes get an image to validate, and on other days it won't, even when it is being sent to the same drive. And many times I thought I finally had the secret workaround recipe, like putting the image (TIB file) onto the same drive as the backup, which slows down the read/writing, so they cannot happen at the same time. Alas, even though that works more often than when going to another internal IDE drive, and that in turn works more frequently than when going to an external USB drive, even that one fails.

I have run MEMTEST32 many, many times, and let it run for many, many hours so for me -- and many others -- that is not the issue.

It is too bad that some of the "massive posters" keep talking about closing this thread, as if sweeping the problem under the rug will make it go away, or that by pretending that the HUGE number of reads of this post and the gigantic number of people who have reported problems are just the product of some demented minority.

No, unfortunately the problem is real, it is a bug, and it persists to this day. Shame on Acronis and their unpaid apologists for not acknowledging this obvious fact.

 

Hello Johnmeyer,

I see that you are still at it then. You started this thread some two years ago and you still have not produced a shred of evidence that the problems you report are not self inflicted.

A while back you said that you could reproduce validation failures "at will". Even further back you stated that you had IFIRC the same problems on four different sets of hardware.
If this is really true you must be ideally placed to reproduce the failures and work with Acronis support to come up either the evidence of a bug or at last to identify the cause which may be in your equipment or the way that you are using it.

Please eliminate the replies from people that have tried to help from the absurd statistics that you are so fond of quoting.

Xpilot

 

Xpilot,

What absurd statistics am I fond of quoting?? The number of reads in this thread and the number of posts are self-evident. And, the number of people who are having the same problem is also something you can see for yourself.

While I am just as capable of being stupid as the next guy, I have run three different software companies, and have some idea which end is up. While I might have been stupid for a week or even a month, many of us have been trying to work this out with Acronis for a long, long time.

This problem has existed since at least version 8 (see this CNET negative review from 2005):

http://reviews.cnet.com/backup-and-recovery/acronis-true-image-8/4864-3682_7-31256880.html?messageID=1023010

I have written to Acronis tech support many times, and I can tell you the first names of all their tech support people. So, I'm not just some guy who likes to lurk around and make trouble. I have tried and tried and tried to get Acronis to fix it.

What really and truly puzzles me is why these "frequent" and "massive" posters, who apparently don't work for Acronis, seem so intent on blaming the messengers who report problems, including me. What's in it for you to take up sides with Acronis? Do you get free beer??

Finally, if you poke around the Internet a little, you will find that this bug has been reported all over the place. Here's a Google search:

http://www.google.com/search?hl=en&rls=GGLG%2CGGLG%3A2005-23%2CGGLG%3Aen&q=acronis+OR+trueimage+corrupt+validate

You will find it has been reported in the UK:

http://www.pcadvisor.co.uk/forums/index.cfm?action=showthread&threadid=319222&forumid=1

on this blog at the PCWorld magazine:

http://blogs.pcworld.com/tipsandtweaks/archives/006753.html

and at hundreds, and perhaps thousands, of other sites. I could go on and on.

Finally, to not just imply, but to openly state that it is MY problem is absurd, unless you think I can somehow cause Google to report thousands of posts about the problems at sites all over the Internet.

My life has been about solving problems and helping other people, so I stand by the words I used when I started this post: "Let's uncover the problem!"

If you aren't willing to help, then please don't post, and please don't blame me for trying to help people fix this problem.

 

I'll volunteer: Me!

After a couple months of ATI support working back and forth with me we found a couple problems and they both had to do with my OC'd memory.

Which seemed to be fine for most Windows apps running at 890MHz (2x2GB of Geil Orange DDR2-800 / PC6400). It would even pass short runs of memtest86+ or MemTestPro (HCI Design).

While small backups to a local internal drive would validate, large files on my Linux file server would not. With their prompting questions I finally realized that this started shortly after I'd gone from 2x1GB to 2x4GB of memory in the Windows desktop. I put the 2x1GB sticks back in and the validations now worked. I then put the 2x2GB and the large file validate problem came back. I then bumped the memory voltage (per Geil) and the problems largely went away (3 out of 4 would work). I then lowered the voltage back down and lowered the multiplier so the memory was running slower and the problems, again went away. I then swapped out the memory for 4x1GB of Corsair XMS2 (CAS4) and slowed the machine down a bit so it was only running around 850Mhz... again, no validate problems.

At a later date I started getting some validation errors again. Again it was on these larger backups that are written to a ext3 drive on a machine that doubles up as a Linux Samba server for this purpose. Since I'd just been messing with that machines memory timings and the amount of OC on that machine I went straight to it. Dropped the FSB by 2 (and therefore the memory by 5MHz) and again, problems went away.

I just recently sprung for V11 because of my experience with V8 and the support the gave me on my V8 even after V11 was out.

But my real point here is, at least for validation errors the memory thing is very real even though I did not want to believe it at the start.

 

Skip Da Chu, thanks for taking the time to post your trials and results.

Unfortunately, johnmeyer seems to have discounted RAM and other hardware problems as being at the root of many TI validate problems. Nobody ever said that RAM was the cause of every validate issue but his outright dismissal of RAM problems and implying people who suggest it were wasting their time was annoying since there were documented cases. It also made technical sense that RAM could be a cause.

Thanks for adding your case to the list.