Top of Information Store.... is a corrupt file 5

[bstep]

I am running NT 4 SP6a, Exchange 5.5, BE 8.5 build 3572 (which was suppose to fix this problem). Every backup returns as failed because as at least one file with the error:
WARNING: "User, John A. [userja]?Top of Information Store?Directory?Sub Directory?message subject" is a corrupt file. This file cannot verify.
Unfortunately this has gone from bad to worse lately because the actualy backup has slown down so much that it is not completing. I let it run for 12 hours (differential backup that normally takes 2 hours) and it is only 1/4 to 1/6 of the way completed. Any help would be appreciated. Thanks.

 

[Zelandakh]

Get that person to delete that the corrupt email. We get these occasionally.

We bin about 4 or 5 a week and it keeps things clean.

 

[dellboy]

As Zelandkh already stated get them to delete the corrupt file and your backup job will show as successful. You should also notice that you will still be able to restore all other mailboxes and other folders within the corrupt mailbox.

You must have verify ticked, which I would reccomend anyway as it shows these problems. If verify isnt checked then you would always assume a full complete backup and that isn't necessarily the case. Why the backup is taking so long I am afraid I don't know.

Cheers

 

[paulm22]

Anyone know of a utility that will clean/remove these files, I have users that cannot identify the bad files to delete them.

 

[dellboy]

I am not aware of any util that will find them for you.

If they can't find them then you'll have to find them yourself or accept reported failures. The error gives the full path of where the corrupt message is, go hunt and delete, good luck

 

[deathstar]

By default when Veritas backs up a CORRUPT file, it will automatically register the job as FAIL. I had this problem with version 8, I had searched the Veritas Knowledge bas and found the solution to this problem.
First of all you'll need to go into the registry, by typing REGEDT32 on the run menu.
1)Goto H_KEY_LOCAL_MACHINE\Software\Veritas\Backup Exec\Engine\Backup
2)On the menu bar, choose 'Edit | Add Value'
3)In the 'Value Name' field type in "Fail jobs on corrupt files"
4)For the 'Data Type' choose 'REG_DWORD'
5)When prompted for the "Data" type in "0" without the quotes
6)Click OK, and then close REGEDT32
This should work, I kept getting corrupt files while performing backups with Backup Exec version 8 and once I modified the registry it worked like a charm.

)

 

[Guest_imported]

You need to test that the file can be restored successfully and 9 times out of 10 it can be, if this is the case you need to alter the registry so that it ignores these errors. Bear in mind though that if you do get a real corrupt file in a users mail box you will not be alerted to the fact! However it does stop the back up from reading failure everyday.

 

[benfolds]

Hi there

I have been having a similar issue with Backup exec. Every night the job fails and when I look in the log it is down to the top of information store error. However I have noticed that the amount of corrupt files and the files them selves change from day to day. The only conclusions that I can come to is that a) the specified files are actually being delivered as the engine scans the users mailbox, or b) the file has been delivered but is flagged as being corrupt, when the user reads the file in the morning it changes from unread to read which seems to clear the problem, or c) both of the above! I have come to this conclusion as I have yet to find an email that is in fact corrupt, they all appear to be fine as well as restorable. I have come to the conclusion that this is an error that I can live with. I don’t want to do the reg tweak that will ignore corrupt files as if there are ever any I will not know about it till it’s to late.

Anyone know any better please feel free to point out the error in my conclusions?

Thanks

Antoni

 

[bstep]

We never actually made changes or found a complete fix for this either. However we found out that part of our problem was that we were doing individual mailbox backup as well as public and private IS. I don't remember everything because I have moved from our Microsoft support, but from what I remember Microsoft told us not to do the individual backup of mailboxes because it either created problems or you couldn't restore it. Sorry I don't remember the specifics. Anyway, we quit doing the individual mailbox backup and the problems disappeared.