Exchange 2010 giving a backup error (see detail). How to find out what the problem is and how to fix it

backupexchangeexchange-2010logging

The error is:

eseutil (2860) JetDBUtilities – 3928: The log file \?\GLOBALROOT\Device\HarddiskVolumeShadowCopy84\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database 0501047257\E000000B4E0.log is damaged, invalid, or inaccessible (error -501) and cannot be used. If this log file is required for recovery, a good copy of the log file will be needed for recovery to complete successfully.

Exchange appears to be running fine at the moment.

I have looked this error up and it looks like the log file specified may be permanently corrupt (I think this is what an error-501 means). Unfortunately a good version of that log file is too old to be on our backups.

There are various suggestions on the internet to run eseutil /mh to check the database and see what state it is in and see if that log file is actually required. Since this all require un-mounting the database, I am looking for the best first step to avoid any problems, for example, if the database won't remount. Is there a way, for example to back up everyone's email before unmounting the database, without going down the pst route?

Best Answer

I've just done an experiment in a VM to try and mimic your situation. I've purposefully corrupted one of the transaction log files and I'm using Windows Server Backup as the backup application. Everything I say below is based on this experiment, but reality shouldn't differ too much.

Even though you say it's all working fine at the moment, you are very right to be concerned about this error, and by asking this question you may well have just saved your future self some grief and panic.

First, some background on why you should be concerned. When Exchange successfully completes a backup, it flushes (deletes) the committed transaction logs, so if your backups are actually failing with this message there's a very good chance that your transaction logs are actually not being flushed and are building up. If the old transaction logs aren't being flushed, you unfortunately have a time-bomb on your hands that may explode at any moment (sorry for sounding so dramatic, but it is actually quite serious). When the volume the transaction logs are on fills to near capacity, the associated mailbox databases will dismount themselves until there is adequate space for new transaction logs. Depending on the amount of transaction logs you accumulate will determine when your mailbox databases will dismount themselves due to lack of space.

You're going to have to dismount the database to do what I suggest, however it should dismount without issue, and when I dismounted my database it was in a Clean Shutdown state, which is good news.

Dismount the database and just do a sanity check and run eseutil /mh <edb file name> to make sure the database is in a Clean Shutdown state. Next, move all of the *.log files except for E00.log and E00tmp.log somewhere safe out of the way (don't delete them, you'll need them back if it all goes tango-uniform). Once they're all moved, mount the database again and try a full backup of the database as soon as possible (it should be a full backup, not an incremental). That process worked in my VM, and hopefully should resolve your problem.

Warning: DO NOT ___EVER___ delete transaction log files unless you are absolutely certain you know what you're doing. If you need to remove a transaction log from the equation, move it somewhere else, just don't delete it.

Related Topic