Strange corrupt .tib file situation

Here's a twist:

I made a full backup of my PC in October and 3 Differential backups since then to my external USB 250GB hard drive.

When I went to recover from a HDD failure that happened today, Acronis applicaiton that I booted from the factory paid-for CD said that some of my differential files (including the latest one I needed) was not a TI archive or currupt.

So I copied the latest differential file to a new file in the same directory, and magically it recognized it ok.

So I started the restore from the bootable CD, and then is said I needed to put the disk in that had volume 1. Well, volume 1 is the original backup from what I can tell and that file was right there and working great.

To be safe I tried to fix the other differential backup archives with the same copying method, and in the end, none of my differential backups are considered proper archive files now. Don't ask me why.

I have 2 other laptops that I tried to work with these files. No luck. I copied them to their internal hard drives and nothing better. So it's not the USB hard drive issue.

I then did an upgrade from build 2.323 to 3.854 and that made no difference at all. A lot of people saying that fixed their problems, but no luck for me.

I even created a new bootable CD from the new version and it didn't help (I was hoping at least that the new build would eliminate the random hanging of this buggy application when booting from the CD, but no....)

I don't see this as a memory issue, and I am really hoping I don't get that run around from support. Otherwise, why are my full backups ok and differential are bad? And why would copying one of them around fix it temporarily?

I really need to get this solved. This is the worst feeling in the world having what is suppose to be a safety net just flat out failing to do the job. I purposely have 2 HDD's so that I can recover fast along with the external 250GB hard drive and a paid verson of Acronis. How could the software leave me flat like this?

 

I just tried downloading the latest 10 version of ATI and no joy.

It was version 9.0 in my post above.

Ugh!

 

Not sure if this is relevant, but are you aware that if you want to validate a differential you need to have all earlier differentials which were made from the same base image. This model is close to how you might expect incrementals to work - i.e. if you destroy an intermediate incremental then you cannot validate or restore a later one. However with differentials it does not affect the ability to restore, just to validate.

This was a known issue in V9 and I understand it was not addressed (so far) in V10.

F.

 

Thanks for your message.

I do have all the differentials on the same drive and in the same folder on the drive.

The problem is with any operation in ATI. Even when you scroll over the files, it immediately tells you "this is not an archive." Because it says this, it will not allow you to even start any operation such as a validate, restore, or mount.

I never did anything to these files. They were just stored on the hard drive. I never moved them, or tried to zip them or anything.

All this means to me is that Acronis managed to program some really flakey code.

I am not feeling too hopeful at this point.

 

Assuming they are all present, it would be unlikely that they would all go corrupt. The next most likely thing would be that the base image is corrupt.

I assume the base is present?
Does the base image complain when you try to select it for validation ?
Can you validate the base image ?

F.

 

I'm wondering if the problem might be the external USB drive.
If you search through this forum you'll find lots of comments about external USB drives and the fact that some of them use chipsets which are buggy.
If I understand correctly you copied one of the differentials to a new file in same directory on the external USB drive. A TI archive file has inbuilt checksums which are used to determine if an archive is corrupt or not. The fact that the copy was recognised as a valid archive indicates that the source differential is OK and the copy was created without being corrupted.
So sometimes at least you can read/write successfully using the external USB drive. Perhaps not always.
I'd suggest you copy each of the full backup and differential images to an internal hard disk then use a checksum utility to compare these source files with the hard disk copies to ensure the copies are bit identical.
Next check the hard disk copies to see if they are recognised by TI as valid archive files. If so, then it would seem the USB drive is a factor. Of course, if some of these files are still not recognised as valid then maybe they truely are corrupted - try to validate them on one of your other computers.
Alternatively, if you can remove the disk from the external USB enclosure you could install it in your PC and see what TI thinks of the files. This way you are working with the original files and not copies.

A later thought: you have used chkdsk on the USB drive haven't you?

 

Well, the problem may very well be fixed.

I paid for a priority support call and used my own web meeting technology to show them the problem live on my machine.

Multiple things seem to be going on here and it's not intuitive.

First of all, the main image has been fine all along, and I recovered from it last night (takes 9 hours for the recovery to finish, why so long).

But the base image is 3 months old and I really needed to use my 2 week old differential.

The root of the problem is that I renamed the differential files so I would better know what they were on the disk.

DO NOT RENAME DIFFERENTIAL FILES! This mistake can't be that well known since support didn't realize the problem. I basically discovered it during the support call.

Then the other problem is that differentials are not independent of previous differentials (this is mentioned in some other threads). This is ridiculous. You can not restore a differential without the previous differentials in place and with them having their original name.

I had 1 full image and 3 differentials. Normally they are named something like this: Backup.tib, Backup1.tib, Backup2.tib, Backup3.tib.

My case was really weird because for mine to work, I had to remove Backup2.tib and rename Backup3.tib to Backup2.tib.

The reason is that before I did backup3, I had already renamed Backup2. Well, don't bother thinking about it too much, just remember do not for the life of you rename the files at the directory level!

This is flat out bad programming. Why in the world would they depend on exact windows file names instead of what's in the header of the files. And why would they need access to all the differentials? It's just a bad architecture.

Also, I had another full image that started to say it was a bad archive, but a load of the latest 9.0 version seemed to fix it.

So in the end, it was nothing with the USB drive or any chkdsk or memory issues or anything sinister like that. It was simply me renaming the files to be more descriptive.

When I renamed the files back, the archive validation worked fine and it's finishing up it's 9 hour recovery at my office as we speak. I saw it just a while ago and it only had 1 and 1/2 hours left, so I am confident it will be successfully done when I get to work tomorrow morning.

 

If you are restoring from the recovery CD this could be a driver issue, does it take this much time to restore from Windows boot CD (e.g. BartPE). Alternatively, I wonder if your link has dropped back to USB 1.1. Have you tried using a different USB port (e.g. one on the back rather than the front).

As I mentioned earlier I think the situation is that differentials can be restored independently, they just can't be validated. That assumes of course that you have not renamed them

F.

 

I have to say, it'd seem intuitive (to me) that differentials do have the same name as the main image. Otherwise how would TI I know which image to reference in a system like mine that has multiple main images and corresponding incrementals.

The not being able to validate is a major coding bug. One thing that might work when images won't validate is to see if they can be mounted and explored.

Colin

 

Wouldn't be that hard to code that information in the file and have the product search that meta data in all the .tib files in a designated directory for the all the files it needs.

Either that, or tell support to know to look for that issue.

 

Well OK, but then you will find some smart-arse who want to change the extension too, and then the program has to scan all files in a directory.

No. I think the current implementation is fine, you are allowed to specify the base name after all, and if you read the files using the product it will tell you all you want to know about the incrementals or differentials. I don't see any advantage to what you are proposing.

F.