Wednesday, June 20, 2012 11:06 PM
I'm posting this as a new question since most similar threads seem to have a Dirty Shutdown state:
Our 3rd-party backup solution (Symantec Backup Exec 2010 R2) has reported "error -528 log file missing" for the last several jobs backing up our Exchange 2003 Standard server. After exhausting all of Symantec's own "fixes", I've determined that the log file on our Exchange server (at C:\\Program Files\\Exchsrvr\servername.log\) is, in fact, missing. There is nothing within the directory.
How do I go about getting the log file back/ creating a new one? Unfortunately, we do not appear to have a good backup of whatever should have been in that directory-- as far back as I've looked in our backup jobs the directory seems to have been empty (even though the backup only started failing recently).
I'm confused because many similar threads discussing missing log files also have information stores that fail to mount, or eseutil /mh reporting "Dirty Shutdown State" on the store. Ours reports a Clean Shutdown state, and Exchange is still functioning normally other than this error in the backups.
The discussion at http://social.technet.microsoft.com/Forums/en-US/exchangesvradmin/thread/2a5a42a8-78cd-4fd6-b05a-fb9fb698525d seems to have an answer, but it's unclear from that discussion whether I should:
A) Overwrite the Information Store from a backup and then replay the log files OR
B) Leave the Information Store as it is, but dismount the database, move the "committed" log files (in C:\\Program Files\\Exchsrvr\\MDBDATA, except the most recent E00.log) elsewhere, remount the DB and then attempt another backup.
Please tell me what the proper solution (A or B above) would be, or whether I'm wrong and it's some combination of the two.
Wednesday, June 20, 2012 11:48 PM
If the DB is running there is no reason to overwrite the DB, instead I would;
- Check to see if your anti virus may have quarantined or killed off the log file. If its available recover it. NOTE: your av software should not be scanning the log files just for this reason
- Do a new FULL backup and see if it completes
- If the full completes then you are fine and all new subsequent incremental backups should be good as well
- Post updates as you find out more information
Thursday, June 21, 2012 5:57 PM
Thanks, Troy-- I have checked our AV logs and though the directory was included (and we've since excluded it), the AV logs do not indicate that anything there was moved, quarantined, or deleted and our AV support assures me that nothing was touched.
The backup is still reporting the same error. So, what do I do? Do I do option B above?
Thursday, June 21, 2012 6:00 PM
Thursday, June 21, 2012 7:47 PM
I have not performed a full Symantec or Windows backup yet. Should I do that first? Even if the Symantec backup errors out again?
Thursday, June 21, 2012 8:09 PM
1. Whatever your main backup product is you should do a full backup with it first
2. Have you been using different backup products? If so you should not use multiple backup products, else one truncates the logs and the other fails because its expecting the logs
Thursday, June 21, 2012 10:28 PMNope, we've just been using Backup Exec. I will run another full backup tonight and get back to you tomorrow. Thank you for your help.
Thursday, June 21, 2012 10:31 PM
Friday, June 22, 2012 3:22 PMOK, just completed a full backup using Backup Exec. It did back up the store but still reports the same -528 error. What do I do next?
Friday, June 22, 2012 6:53 PMSorry for the delay, busy day.... Anyway...
- Very odd, so are you getting the -528 at the end of a FULL backup or only when you do incremental backups thereafter?
- Look at the detail of the backup, did it truly succeed? Symantec has this goofy area where they can succeed with errors which is not a success
- Also look at your Application Event log and see if there are any errors regarding Exchange
Monday, June 25, 2012 2:45 PM
The -528 error happens at the end of a Full Backup job (specifically, the First Information Store backup is "Full - Database & Logs (flush committed logs)" and the associated file backups are "Full - reset archive bit").
This is even more interesting: I just ran an off-schedule backup that I created using the same backup policy as the nightly job (the one we're discussing here which has been failing). The only changes I made to this policy in BackupExec were to strip out other servers that get backed up in the same job (to make the job run faster as I was running it during business hours).
This new job was also a Full Backup identical to the failing job. But this one SUCCEEDED! Digging back through the log of the successful job, the only difference I could find was that for whatever reason this time BE backed up the Exchange Server's Information Store FIRST, then did its file backups of the server's disks second. (In the failing job, the Information Store is backed up AFTER the rest of the drives/files). BE reports no errors in this job.
I'm not seeing anything telling in the Exchange logs, either when the BE job is running or otherwise.
One thing that's still confusing to me: even as this new job succeeded, there is still nothing inside of the c:\Program Files\Exchsrvr\SERVERNAME.log directory on the Exchange Server. Is there supposed to be something in there?
Monday, June 25, 2012 9:54 PMHmm yeah sounds like there is something in the old job definition is doesn't like. I have seen that before and chasing it down can take some time so you might try removing the Exchange databases from that backup definition and creating a job just for the Exchange database backups.
Tuesday, June 26, 2012 5:42 PM
Troy, thank you for your help. Last night the "old" BE job ran for the first time since I'd done my (successful) one-off Exchange server backup job, and this time that "old" job succeeded with no errors.
It seems that successfully running a separate BE backup job containing just the Exchange server in my selection list was the solution.
Still don't know whether it was a change in the resource order or something else about the separate job that caused it to succeed, but once it succeeded the original job succeeded, as well.
- Marked As Answer by herbuveaux Tuesday, June 26, 2012 5:44 PM
Tuesday, June 26, 2012 5:48 PM