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

I did some Web research on data corruption that is relevant to this discussion. Please see https://www.wilderssecurity.com/showpost.php?p=1246498&postcount=74 and https://www.wilderssecurity.com/showpost.php?p=1248200&postcount=80. This first link lists some free programs you can use to add redundancy to your backup files. If you use one of these programs, you'll need to make sure it is available from an alternate operating system installation, such as a BartPE CD. These programs can cure corrupted files, and may be a good investment for those of you with a lot of corruption problems. If you use one of these programs, be sure the backup verifies successfully before creating the redundant file(s). I realize that this may not be possible in some cases, given the nature of some of the posts I've seen. However, these programs can protect you if the corruption occurs at a time later than after the redundant files are created. I'd recommend creating the backup on the device which works successfully most often for you, then do a validate, and if successfully validated then create the redundant information with one of the programs mentioned in the first link above, and then copy or move the backup files and redundant information files to the final destination. If reading from the final destination is a flaky operation, then you may wish to copy the backup files and redundant information files back to the most reliable device before doing a restore. If corruption is found during a restore, then you'll need to run one of the programs mentioned to make the necessary corrections to the backup files, and then try the restore again.

 

A general suggestion: if you find a version of a backup program that works reliably for you, don't be hasty to update to newer versions. Newer isn't necessarily better.

 

I haven't time to read all posts in this thread, if a similar post was made I apologise.

I had a corrupt image, after thinking about it I set my TI 11 to :

In Tools / Options :-
compression level = none

Backup Performance :-
Backup Priority = High

HDD Writing Speed = From minimum, at the 6th mark
Network connection = the same.

I have not had a problem since then, and that was months ago.

 

The thing that everyone seems to miss in all this is that every read and write operation in your computer must be 100% correct, and must complete with no errors. If not, you get something bad, either a message: the old DOS "abort, retry, fail" or BSOD or something. Now it is true that "under the covers" there may be bits that get screwed up and don't come across correctly. This happens all the time with optical media. But all mass storage devices have error detection and correction built in, and the Windows (and Linux and DOS) operating systems all use that to determine whether stuff has been transferred correctly.

If what I just said wasn't true, and if your computer failed as often as TrueImage thinks it is (I am getting corrupt image failures on over 50% of all my backups), then the computer would not function. If you copied or installed a program, and one byte was corrupt, that program would not function. Word processor documents would fail to load or would have strange characters popping up. And on and on. This isn't happening because it can't happen; the Windows O/S does error checking and correction.

What IS happening is that Acronis has developed their own code to write to disks and that code has bugs. This isn't a "maybe" or "perhaps." It is 100% certain because if all the dozens of people in this thread and the dozens and dozens more that have posted in other threads all had corrupt memory or bad disk drives, etc., they would have experienced other problems. The fact that this happens with larger files is a red herring; one large file or 1,000 small files that equal the size of the large file both will fail with the same frequency.

 

Thanks for the useful replies to my earlier post. I was hoping that I had finally found a foolproof back-up methodology - apparently not. I still think I need to try restoring to a new (independent) disk to see how the backups actually behave with a full restore. I was hoping to avoid replacing RAM, cables or whatever on a PC that otherwise behave perfectly. Nasty!

 

Well, at the risk of boring regular readers, I will recount my backup methodology which as far as I can tell after more than two years solid use is actually foolproof.

Backups run to schedule automatically on to a secondary internal drive. There is space there for 8 to 11 full main drive backups.
I do not bother with validations, instead after an image has been completed, I withdraw the source drive and replace it with one from a previous day. A restore is then run and that is it.
In the extremely rare event that a restore fails I have a range of options. I could put the original source drive back and ignore the problem and just make a note that the latest image is corrupt. More likely I would put the source drive back, re-image manually and then restore again to a swapped drive.
After many hundreds of image/swap/restore cycles and only a handfull of restore failures I ran into a clutch of them and then a POST check said that no drives were present. This escalation made the tracking down of the problem a simple matter. I first had suspected a data cable problem, this had already been replaced and the fault was a poor 5.5Volt connection to the main drive's electronics.

Of course I cannot say that there are hardware combinations out there will not cause True Image some dificulties. A different approach of making actual restores to a swapped drive cuts out the sometimes problematical validation step and the whole process is risk free.
At no time did I think that the TI program was faulty in any way. I always suspected some sort of hardware problem and this turned out to be the case.

Happy restoring.

Xpilot

 

That is correct. There are free programs such as Roadkil's Unstoppable Copier that can be used to salvage whatever is readable from a file that your OS has declared corrupt.

Here is the software needed in a recovery toolkit:
a) Either QuickPar or ICE ECC for creation of redundant files. I believe both are available in portable versions. Put a copy of one of these on a USB stick, floppy, BartPE plugin, an alternate disk drive, etc.
b) Either Roadkil's Unstoppable Copier or IsoBuster. I believe both are available in portable versions. Put a copy of one of these on a USB stick, floppy, BartPE plugin, an alternate disk drive, etc.
c) BartPE, a bootable Windows CD. You'll need this to run the above two programs in emergencies, and also to copy files between devices if necessary.

Then you can follow the instructions in my previous post.

I don't bother to do any of this, because I burn a copy of every (verified) backup file to two separate DVDs that are verified by the DVD burning program. And, as johnmeyer alluded to, DVDs do use Reed-Solomon encoding for error detection and correction. Hard disks also do use a form of error detection and correction, but it is localized to specific sectors. Thus, enough damage to a specific sector can result in your OS reporting that a file is corrupt. Roadkil's Unstoppable Copier or IsoBuster can salvage the readable parts of the file in such as case, which is useful if you've previously used QuickPar or ICE ECC to create Reed-Solomon encodings.

I don't believe that ATI goes to this low of a level, although I suppose it's possible. I do believe, however, that the code in some versions of ATI is flaky in how it interacts with the OS file code. That's why I recommend that if you find a reliable version of ATI on your setup, to keep using it, resisting the urge to upgrade to newer versions. On my system, a different version of ATI caused a verify failure every time I tried it, but the version of ATI I use now has never had a verify failure, to the best of my recollection.

Some systems are known to have a problem with only very large files, as previously alluded to in posts by others.

 

When you do a successful restore, you actually are also doing a verification. Your experience with only sporadic restore failures, followed by a bunch of restore failures, speaks to the importance of doing regular verification, whether manually or invoked by doing a restore.

 

Some others have mentioned using MD5 checksum programs for verification that two files have the same contents. I use TestPath for such purposes. It is free for home use, and shareware for corporate use.

 

I obviously did not explain my method very well. To put it another way in the form of a question. Why does one run validations? Answer to have more confidence that a restore will work.
I just cut to the chase and do a restore with no validation. The reason it works is that the fit and working source drive is not overwritten. It is removed from the computer before the restore is run.
The replacement drive is then the working drive and the original source drive becomes the perfect known working backup.

Xpilot

 

There are two areas where most backup programs are theoretically vulnerable, even assuming the backup program has no bugs. Here's why: during backup, 1) data was read from the source, and 2) written to the backup. During the restore, 3) data was read from the backup, and 4) written over the source. Corruption could happen during any of these 4 steps. If I understand correctly, verification in most backup programs aims to provide detection of corruption in steps 2 and 3. However, for most backup programs, if my understanding is correct, verification provides no detection of corruption in steps 1 and 4. Thus, things are not perfect even if you use verification, and even worse without it. A backup program could theoretically do a separate comparison, both in steps 1 and 4, to overcome these weaknesses, but I'm not sure if any backup programs actually do it. If somebody knows of such programs, please let us know. Doing a byte-for-byte comparison in step 1 between original and backup is indeed possible even during backup of a live system, because the backup program can simply copy any changed sectors to a buffer and then use the buffered copy instead of the changed sectors for comparison. This is what already happens anyway when you're backing up a live system.

 

Your method is indeed sound. My point is that when you're doing a restore, the backup program is already reading the backup files, and also doing a verification concurrently. That is why your backup program may complain about a corrupt backup. If your backup program wasn't doing a verification during a restore, how would it know if the backup is corrupt? All of the data needed for the verification is inside the backup files. The concurrent computation of checksums during restoration is not a bottleneck on a modern processor.

 

I have found a program called TestIO that can test if your system can read and write files on a given device reliably. I tested this program on a virtual machine, and it worked. The documentation mentions that the program is for network reliability analysis, but it can be run from a non-networked device also. Run it on all of the devices you use in your backup software..

 

I found three more programs to test for data corruption issues. I started a separate thread because it may be useful to a lot of people who wouldn't bother to go through this long thread.

 

Obviously that is a good method and it is done by various other applications. Unfortunately, it has a couple of shortcomings as well. The first one is that it is difficult to do with live imaging since the disk contents change during Windows operations. I don't know if it would be possible to keep the disk state frozen to do this. If only the Linux boot CD was being used then it could be done. The second is less of an issue but you would lose the ability to do a validation on the archive at any time and place since the source is no longer the same or available. Of course, you could implement both mechanisms.

The "archive corrupt" message really means that the archive can't be read properly for whatever reason and in only rare cases does it mean that the archive itself is garbled internally.

 

This is possible. In fact, ATI already does it when doing live imaging. What happens during a live system backup is that changes to sectors are allowed, but before the changes are made, ATI copies the existing contents to a buffer. ATI then knows to use this buffered copy instead of the changed sectors. The same idea could be implemented for also verifying that the written backup data matches the original data.

 

Thanks for the "test programs" thread. I'm one of those who have trouble w/"corrupt archives" in TI11 though TI7 continues to work just fine (I've uninstalled TI11 until I see an update purporting to fix some problem(s)).

Given that there seem to be a number of people here who know ALOT about TI, and ALOT about the issues involved, I hafta ask: is there any evidence anywhere on this board to suggest that TI developers understand and are working on a problem? I sure don't see it, i.e. you'd think you'd see an Acronis individual pop-up somewhere wouldn't you?

 

Possibly, like I said, I don't know the internals of TI to definitely know if this is indeed possible or does it cause some other problem.

I'm not really convinced that implementing this method would really make things appreciably better. The main problem TI has for restoring is incompatibility of the Linux rescue environment and if you can validate an archive with the Linux rescue CD your probability of restoring it is good. From what I see, "corrupt archive" implies the archive is garbled but really means that you can't read it properly and its contents may be perfectly fine.

A major issue in validating an archive is the necessity to validate using the Linux environment for the first few times to build confidence it works with your PC. Windows does not restore the active partition, Linux does unless you are using Bart/Vista PE. A move by Acronis to providing this environment for restoration would do far more good than changing validation mechanisms.

To go back to the original title of this thread concerning the cause of corrupt archives, my opinion is that they are caused by the Linux issue, faulty hardware, TI programming issues that don't work reliably on all PCs.

 

Which versions AND BUILDS of TIH should we use?

I tried again (on 30 Mar 200 to make an image using TIH_11b8053; the image was OK (I am using in my XP Pro laptop the new HD built using that image) but the W2K system where the backup was done has again got apparently (I din't check yet) FS problems in areas that TIH shouldn't touch. Next time, I'll uninstall TIH_11 and reinstall TIH_9, but I don't remember which build I should select (of the 4 I have downloaded: b2323, b2337, b3633, b3854, I used 2; 1 was bad, maybe b2323; and 1 good, probably b3633).

Please can you tell us which build(s) of TIH_7 were good, and where we can download them? Does a newer license entitle us to use them?

I don't think there is any hope on this side. Acronis seems entered in the PR-damage-control stage: likely none at the company understands the program any more, they just try to add minimal superficial fixes or improvements to the products, and devote the main of their resources to polishing image and maximizing sales. I often saw this in development teams: nowadays, programers who built something really big are often gone, only remain hords who essentially don't understand how the programs work and can just guess how to superficially change a few bits to "justify" a new "upgrade"; if ever someone tries to really understand and improve the core of the product, he is perceived as a threat to others and accordingly singled out. I hope this is not the case though...

Versailles, Sun 25 May 2008 17:55:35 +0200

 

You're welcome . I was surprised to see that a Google search turned up no previous mention of any of these programs at Wilders.

 

Re: Which versions AND BUILDS of TIH should we use?

ATI 9.1 Build 3534 has worked well for me.

 

I forgot where I read this, but I did read it online somewhere. You can test that it does this by changing a bunch of files in different places after a live system backup has started. You should see that the backup contains the version of the files at the beginning of the backup, not the changed versions.

 

All of the things you listed can cause "corrupt archive", I believe.

 

I just did a backup in Windows, monitored with DiskMon. Source data is not read in the verification step optionally done as part of the backup, which verifies what I previously assumed.

I just did a backup in Windows, monitored with DiskMon. The reads and writes from ATI showed up in DiskMon. This shows that ATI is relying upon Windows for reads and writes from backups made within Windows.

 

Re: Which versions AND BUILDS of TIH should we use?

I have used (the last, I believe) build 638 or TI7 for years w/o issue. I have no clue where you'd get it or whether a newer "CD key" would work with it (I doubt it).

Do you know something for a fact or is this just wild (reckless?) speculation on your part?