Images always corrupted

This was a common problem with thos older versions. Sometimes the the porb was a far out place in mem that was bad -- since most operations don't use those farther reaches the prob rarely shows up. You could use th free memtest to test your mem, running for 8 hours or so.

Other than that, your choices are to try diff hardware or a diff versin of ATI or a diff backup program. I'd recommend ATI 10 if you can find it but only after ruling out any memory prob.

This happened to me too. MEMTEST is your friend! http://www.memtest.org/
Once I had replaced the memory chips, all worked OK.
Rog

Ocassionally, just removing and reseating the memory cards is all that's needed -- certainly worth a try if you have the time to wait for memtest to tun again afterwards.

So, now I tested my RAM with memtest.
Result: NoErrors
But now i will test ATI 11 Home.I got a free version from a computer magazin called Computer BILD.
Thank you for your answers.

If you have an old ASUS A7V133 motherboard then the problem is due to a faulty chipset. The issue was never fully fixed by ASUS - they tried but never got a driver which overcame the problem.

I had this motherboard and did intensive investigations of the problem.

However, it's much more likely that you have memory related issue. Are you overclocking?

I'm not sure but I think there were problems with TI8 (and possibly TI9) when using external USB drives.

Do a search on the old Acronis forum at Wilders:
http://www.wilderssecurity.com/showthread.php?t=250972

The "archive is corrupt" message should really be interpreted as "TI can't read the archive and reconstruct the numerous checksums properly".

Anything that can cause this situation is a candidate. It can be anything from a bad sector on the disk storing the archive, bad cable, bad RAM and as one user found out, a bad processor. A poor Windows driver for the device may cause it as well. You can change the software environment by booting up the TI rescue CD and doing the validate using the Linux environment. However, the Linux driver often are more of an issue than the Windows drivers but not always.

You can do a similar test as the validate but with TI out of the picture. Take a large file, and you can use a TI tib fle for this, and calculate its checksum MD5, CRC or whatever you please using a free checksum calculator program. Record the value on paper and then using Windows, copy the file to the USB drive. Run the checksum program on the USB file. The result must agree, if it doesn't it means the file didn't copy properly. If it does agree, copy it back to your HD and run the checksum calculator again. Every checksum calculation must be identical.

This is pretty close to what TI does except it writes and compares 4000 checksums/Gb of data and every one must compare perfectly. One bad checksum and the archive is declared corrupt.

Thanks again for your answers.
But know I made a new test, with TI 8 and a new USB HD from WD. I convert its filesystem to ntfs and start a new image.
And it works. No more corrupt images. Yiiha.

Seekforever wrote:

The "archive is corrupt" message should really be interpreted as "TI can't read the archive and reconstruct the numerous checksums properly".

Anything that can cause this situation is a candidate. It can be anything from a bad sector on the disk storing the archive, bad cable, bad RAM and as one user found out, a bad processor. A poor Windows driver for the device may cause it as well. You can change the software environment by booting up the TI rescue CD and doing the validate using the Linux environment. However, the Linux driver often are more of an issue than the Windows drivers but not always.

You can do a similar test as the validate but with TI out of the picture. Take a large file, and you can use a TI tib fle for this, and calculate its checksum MD5, CRC or whatever you please using a free checksum calculator program. Record the value on paper and then using Windows, copy the file to the USB drive. Run the checksum program on the USB file. The result must agree, if it doesn't it means the file didn't copy properly. If it does agree, copy it back to your HD and run the checksum calculator again. Every checksum calculation must be identical.

This is pretty close to what TI does except it writes and compares 4000 checksums/Gb of data and every one must compare perfectly. One bad checksum and the archive is declared corrupt.

The gremlins are loose again !! An old problem of corrupted archive re-appeared today despite a suitable "work-around". My Toshiba laptop with 2 HD partitions & external USB drive seemed to properly backup the HD using TI Home 10.0 build 4942 in "Linux mode" until today. Now the E00070020 err msg resulted during archive validation on the USB drive.

If i understand your quote correctly (and Acronis' recommendation) my next test is to backup the HD partitions to the HD itself eliminating the external USB. If the validation check & checksum test both work it SHOULD restore properly. Since i plan to restore to another Toshiba laptop (similar to the current one) the backed up image can (hopefully) be copied from HD to external USB for restoring.

Do you agree with this plan ? Thanx.

Bewildered Bob
Palm Bay, FL

Yes, worth a try but remember if you are copying the image to the external and restoring to the second computer from the external, it has to be able to read the archive properly, What I'm saying is that if you are using the USB external that fails now, it might fail when you try to restore from it.

It appears something has changed on your machine since it worked and now it doesn't and it isn't likely you changed any hardware being a portable. Since you are using the Linux CD for backup, you are dealing with a static disk and no Windows or installed application interference.

If your idea doesn't work, I'd run Memtest86+ overnight on the Toshiba with it plugged in (not on battery alone). I also recommend that any work with TI be done with a portable plugged in because it does cause the power consumption to go up.

PLEEZE HELP ME !
This situation becomes more interesting with each attempt. The config is: Toshiba laptop running Win XP/SP3 with one 80 GB HD partitioned as follows -
'C' = 60 GB
'D' = 20 GB (data files)

Using Acronis TI Home 10.0 (build 4942) CD in "Linux mode" the following full backups were run successfully & BOTH IMAGE ARCHIVES ON HD VALIDATED OK -

'C' -> 'D' ("high compression)
'D' -> 'C' (normal compression)

It was VERY encouraging that the backup images validated properly on internal HD since lately backing up to external USB drive (which was surface tested earlier) consistently fails.

Each image was then copied (or "sent") to external USB for subsequent restore (on a different Toshiba).
However checksum MD5 was run on both images (first while on HD then on copied image on USB). Neither checksum matched (USB vs HD) - not even close. Based on the previous explanation of checksum function, the testing stopped here since it was unlikely that the image would restore properly from USB having failed the archive validation.

But IMHO these results APPEAR to eliminate some of the possible causes of validation failure (RAM & many other PC components unless the USB port itself could be causing the failure). If true, the most likely cause is related to the USB drive & its cable. But this test has been done with 2 different external USB drives & cables so the mystery continues.

I prefer NOT to run 10 hour MEMTEST if my experiment proves that RAM is OK. Any other suggestions will be GREATLY appreciated.

Baffled & Bewildered Bob
Palm Bay, FL

Bob,
Have you tried other USB ports? They can fail. You could check the drives on another machine but since 2 different ones fail it is not as likely they are the problem.

Since the MD5 checksum test is similar to the TI validation it can also fall victim to bad RAM as well. However, the fact that you can validate the archives with TI pretty well rules out the RAM and other hardware issus as far as the internal HD archives go.

I will try using another USB port during next test.

When this problem first occurred (over a year) ago Acronis stated that my hardware was the cause. At the time that seemed unlikely since no other program failed. Apparently TI does some unique stuff that severely tests the hardware. Are other fully functioning disk-imaging pgms less rigorous but still provide backup protection ? Right now my HD cannot be restored.

Bewildered, battered & baffled Bob
Palm Bay, FL

ps: Another remote possibility is DATA COMPRESSION. Some of the infrequently used files on the HD are automatically compressed by Windows to conserve space. However when the data is backed up another compression (normal, high or max) is also performed. Could multiple compressions confuse checksum & validation ?

Data compression should not cause a problem when dealing with files compressed by Windows. There are all sorts of other compressed files on the disk too such as jpg, mpeg, zip etc. Also, by booting and running the CD version Windows is out of the picture.

TI does pick up problems that normally might not be seen because it runs quite fast (high data throughput) and rigourously checks the data once it is in RAM not just by looking at a CRC error that the HD might display if it catches an error it can't recover. TI is also dealing with very, very large files and also checks every 256K bytes of data with a checksum. If you can't get the MD5 checksum program to duplicate the checksum with the USB drive, I doubt if Ghost or anything else will be happy either unless it is a TI coding problem. Since it was working, that is unlikely.

Have you run chkdsk on the USB drive? I would run chkdsk X: /r on the USB drive. Replace the X with the drive letter of the partition on the drive you are testing. If it fails on one USB port try another.

Since you can make an image you can validate to the second internal partition on your HD, you could split the image to DVD size pieces and then burn them to DVD using a DVD buring program. Yes, I know TI will burn to DVD but I would prefer to do it this way. Be sure to use the burning program's "Verify after burning" feature. You could then read the image on the second laptop which is what I think you want to do.
Normally, I don't care to use DVDs but it appears you may have a USB drive issue of some sort.

IT WORKS - FINALLY !!

Thanx to Seekforever for V-E-R-Y valuable insight and suggestions. After a L-O-N-G time and M-A-N-Y failed tests, an image of the HD was successfully backed up (in "Linux mode") to external USB drive, verified and restored. Altho i'm not completely certain of source of the problem, these steps made the difference:

(1) initially backed up the 2 HD partitions to INTERNAL HD images & verified (twice). This successful verification alone seemed to indicate that the external USB may have been the cause of the problem.
(2) ran thorough surface-analysis of the external USB drive using a heavy-duty utility provided by Western Digital (manufacturer). Re-formatted the drive.
(3) switched USB ports - the one previously used for attaching the USB drive was switched to another device. There had been no prior indication that this port may not work properly.
(4) specified "no compression" during backup (which had been tried earlier without success).
(5) instead of separate partitions (step # 1) the entire HD was backed up to a single image on USB.

One additional goodie that i never expected - the restore was tested using an older & smaller 60 GB HD (to preserve the integrity of the 80 GB "live" HD). The restore was smooth. Obviously the partition sizes are smaller but the restored image works well !!

Maybe the alignment of the planets was favorable this time but i'm EXTREMELY GRATEFUL that my HD is now properly backed up ready to be restored if needed. To those folks still struggling to make their USB drive work properly, don't give up - you MUST have proper backup !!

Blissfully backed-up Bob
Palm Bay, FL

Solution to Event code: 0x000101F6 Operation with partition was terminated

Details: Operation with partition '0-0' was terminated.
Details:
The archive is corrupted. (0x70020)
Tag = 0xF5F8CBCF76155639

More information can be found at: http://kb.acronis.com/errorcode/
Event code: 0x000101F6

I hope this can get published somewhere to help everyone out there ... including Acronis & maybe even me Hint hint (free software or something perhaps) hint hint ... as so far, in all my searching I haven't come across the following solution.

I must point out however that for "try and decide" in TI Home 2010 Acronis does warn to turn off background defragmentation.

I was having terrible times getting any kind of reliability with validation, or mounting of images. Random failures galore including a restore that went terribly wrong and left a Netbook unbootable (Netbook = NO optical drive so had to create bootable USB Key etc etc I have much less hair now !!!)

Anyhow ... I was backing up using True Image Home 2010 on Windows 7 starter edition 2 GB ram to a Lacie 1 TB USB external Hard Drive. Never even thought of it but had the Lacie supplied "USB Boost" program running in boost mode. (does it automatically when drive is present)

Since turning that off while using True Image No more problems

I will wager that all these "USB Boost" type apps cause similar problems.

Hope this gets looked into and solved. But after many frustrating hours of troubleshooting I now have 100% reliability

Kami,
Vancouver
Canada