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?
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 aClean Shutdown
state. Next, move all of the*.log
files except forE00.log
andE00tmp.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.
The Error "501- JET_errLogFileCorrupt" means that the log files are damaged.
Use following steps to check the log files status:
4. Run Eseutil /r, now recheck the database state with Eseutil /mh command if it is in clean shutdown then mount the database with Mount-Database cmdlet. 5. If still the database is in Dirty Shutdown state then perform hard recovery. But before running Hard Recovery, read this Microsoft doc:
https://techcommunity.microsoft.com/t5/exchange-team-blog/repairing-exchange-databases-with-eseutil-when-and-how/ba-p/610276
You can also check this video for step by step guide: https://www.youtube.com/watch?v=JYjAaAWDQL4