question about corrupt archives

I recently tried to do a recovery (from rescue disk) and TI immediately flagged the archive as corrupt. Fortunately the one from the prior week was OK, so I just used that one.

My question is this: I didn't actually verify the image in question at the time I did the backup, so I'm not wondering how it got corrupted, I'm just curious how TI knew it was corrupt immediately after selecting it.

I have verified backups in the past, so I know it takes almost as much time to verify the image as it does to do the backup, so I figured it would at least have done some crunching before declaring it corrupt. Instead it was flagged as corrupt immediately after I selected it and hit the "next" button.

Can someone explain this to me please?

 

I don't know exactly how TI process the archive but this is my understanding of what might have happened in your case.

When TI creates an archive it formats the data and writes a checksum for every 256K bytes of data. It also writes metadata (which describes the structure of the archive) at the end of the archive.

When TI opens the archive upon selection, it probably quickly looked at the metadata and perhaps the first few blocks of data. If the metadata was incomprehensible or if there was a bad checksum the archive would be seen as corrupt. It only takes one bad checksum to have archive declared corrupt.

I think it is more likely it was a bad checksum since bad metadata seems to cause the "not last disk in archive" or something similar message.

I would expect a CRC error from the basic disk read to give a Windows error unless TI traps it and issues its own message.

Did you run chkdsk /r on the partition the bad archive was stored in? You might have a bad sector.

 

I did not run chkdsk on the partition. The weird part is all the archives I had available except that one (about 6-8 more of them) all verify OK, and I've never in the past had any archive that didn't verify properly. I even stopped verifying because it seemed like a waste of time. I only do full backups, never incremental or differential, just for that reason, if anything gets corrupted it only takes out one backup, not a string of them. I'm back to running verify again now at backup time just to be safe.

There was another weird thing that happened at the time, my main C: partition which I was trying to restore became unallocated during the process. But because of the corrupted image I never got to the step where it deletes the old data and starts writing the restore before the partition disappeared. It seemed to happen when I tried to do a verification on the corruped archive, but aborted the verification because it was going to take an hour. Very strange indeed, but it appears to be just a fluke thing that I'll probably never understand what happened.

Its possible that the checksum failed in one of the first 256k blocks, and that's why I got the immediate corruption notice, but that just seems odd to me since I've never seen any corruption issues in the past using the same external HD.

 

You can set an option so the archive is automatically validated after the backup process - that makes it a one-step process, instead of having to go back after creating the backup and starting the validation.

Makes it a little easier.

 

It is possible there is a bad spot on the external HD and that archive happened to land on it. The /r option for chkdsk causes a full surface check of the partition by reading all the partitions both allocated and unallocated. This happens after the file structure is given its check. I really think you should do this so you can know what you are dealing with - would you trust anything written to the USB drive now? It may be one of those funny PC things that will never be understood but why not check it out.

 

I checked the HD and found no errors at all (took about 2 hours to run chkdsk). That's pretty much what I expected to find.

Regarding the corrupt archive, as I said before, the immediacy of the error was very suspicious, as if TI had just lost its mind or something. I see so many reports of corrupt archives on this forum it would seem there's something going on with TI, there can't be that many bad hard drives out there. For now I'm calling this a TI hiccup, and going to forget about it. Since I have multiple images to choose from it wasn't a problem this time, and shouldn't be a problem if it happens again.

Since having this problem I've read a little more on this forum regarding corrupted data, and now I'm starting to feel like I should be happy to have any non-corrupt images on my USB external HD. Seems like there's so many cases of corrupt archives on USB HDs that Acronis should release a new build with some debug capability so when it happens we can provide them with some insight into what happened to cause the corruption. I know these things are very difficult to track down, but the first step would be to allow us to provide them with data to start looking into it.