Corrupted TIB file turns out not to be corrupt

This may be valuable information to someone. A horror story with a happy ending. I hope it helps.

I did a full image of my HP laptop harddrive a few days ago, saved it to a Maxtor 300 GB external drive (USB). The image was a little over 30 GB.

Two days later, something very bizarre occurred with my computer, not sure what, but it hosed the OS (WinXP Pro) when I powered off. It appeared to be locked up just prior to my turning off the power and I didn't know what else to do. The laptop blue screened on reboot. Thinking it was the harddrive, I called HP on my support plan. They had me reformat the drive to see if the drive was okay, and if okay, I would then restore my drive image. The format went fine. The restore didn't go so well. No luck. I got the dreaded corrupted TIB file, restore failed, image corrupted type message. I tried this forum and got completely freaked out that my chances of restoring were slim to none.

Some of the suggestions included get the latest build (I was using 2273). So I downloaded the latest build - 3677. Still no joy - same corrupt archive messages.

So this is what I did that was successful:

1) Installed the Maxtor 300 GB on computer #2 (a Dell desktop).
2) I went to the command prompt and copied the 30GB file from Maxtor 300GB to a Buffalo 400GB drive. It took several hours for this operation to complete. But my faith in the old DOS copy command is very high and I'm sure there is plenty of error checking to ensure a perfect copy.
3) Then I used the latest build boot CD and I did a verify and restore from the networked Buffalo drive. This entire process took about 12 hours. It worked. So I'm back in business.

Some of the messages on the forum were frightening that there is so little hope, that these error messages indicate what they say (i.e., if it is says corrupt, it probably is). But something didn't make sense to me. If the backup went without error, the file should be okay, shouldn't it?

This is what I expect of drive image software:

1) it is bullet-proof - no excuses
2) it does what it promises to do
3) it doesn't lead you down a wrong path. Why give an error message that is, in my case, demonstrably incorrect? I was told my archive was corrupt. It wasn't. The error message is plain, flat out wrong. How about a message like "your file may be corrupt. It could also be blah or blah or blah."

Point #3 to me is inexcusable in TI and it needs to be fixed. As it stands, I could have easily blown away a good archive, lost a lot work, lost a lot of time and so on. I'm quite soured on this because Acronis got paid for their software. Yes, it did do the job it in the end, but it also didn't help me along the way and in fact, it misled me along the way and it was only through my own persistance that this story has a happy ending.

 

The point you made in all that was that you "COPIED" the file from one HD...to another. This usually solves the problem with DVD's, but since you had the file on another HD and copied it over to another, then I don't understand why it gave you a "corrupt" message.

But however, I've noticed a lot of times that when it says the "file is corrupt", ...making another copy of that very same file ...seems to do the trick. It could be a setting it's saving with the actual archive file itself, and coping it solves the problem. Why...I don't know.

 

If there is a problem reading from the USB drive, the verification can fail because it calulates a wrong checksum due to the error in reading. Of course, one would expect that writing would be more likely to create an error and that the image would indeed be corrupt, but in this case that was not the situation.

Computer number two was able to read the USB drive without errors, so the image could be copied correctly. Once the image was on a different type of drive, it could be read correctly by computer number one (read via the NIC instead of the USB port).

The most interesting part of this is that writing to a USB device apparently went without errors while reading from that drive generated errors. Very surprising.

Since the failure to verify the image was due to a hardware problem, TI is not totally to blame, but the result is still frustrating.

Perhaps TI needs to add a hardware qualification procedure so that inadequate hardware is identified before backups are made.

 

It would be interesting to know if TI could validate the USB drive image using the second computer that was used to transfer the file to the Buffalo.

 

If I remember correctly, I tried that (w/o success). Unfortunately, I didn't write down everything I did, but I did things like try different cables, a couple of different USB ports.

 

I do see a potential problem using USB drives with ATI. When you create a backup image you are using windows drivers which are, presumably, the correct windows drivers for the USB interface you are using. When you boot from the CD you are using whatever USB drivers Acronis put on the CD which may or may not work well with your interface. There are many variations of USB hardware out there and I can't believe TI works well with all of them. You might have been better off burning the image to DVDs and restoreing from DVD rather than USB. I think it's a good idea to always split the image to DVD size files even when you don't intend to burn it, you may need to later.

- Mooron

 

You are quite correct in your assessment of TI and USB drives; the Linux drivers can indeed be a problem and not all chipsets are created equal.

I would prefer to get a USB drive working (or one that works) than go the DVD route since I find it slow and optical media can vary in quality. Generally, I think you'll find that once you get a USB drive that works and the TI program is running well for you it will continue to do so until something breaks.

I fully support the idea of splitting the file to a size that will fit onto DVD just in case there is a problem.