What are Exchange log files and why are these so important? Well the log files in Exchange are basically a temporary location used by Microsoft Exchange until the email or objects have been full committed to the database. While you are sending/ receiving emails, contact, journal calendar or tasks, that data is not stored directly into the database. These are passed through the server memory and transaction logs files, then these are moved to the database where the data is committed.
Below is a brief explanation of the three parts of Exchange data movement.
Server Memory – This is the first step where any newly created transactions are stored and cached. After this step, the items are saved in the log files.
Exchange Log Files – This is a temporary location where the transactions are stored until these are committed to the mailbox database. All transactions are first saved to the log files. This is why during the day your Exchange data location will have a considerate number of log files and when you do an application backup the log files are purged. This means that all the data in the log files has been committed and stored into the actual database.
Mailbox Database – Here is where the actual data resides and where all the mailboxes are stored
Now you know the three parts of the Exchange server which take control of how the data is stored and moved. Why am I explaining this? I am explaining this to show the importance of the Exchange log files. We all know that usually log files are not important for the integrity of the data, but in Microsoft Exchange Server, these logs are a vital part for the database health and a functional server.
When you manually dismount a database, all the transactions which are in the memory and logs are flushed into the database and any pending transaction is committed to the database.
This is how it works on normal behavior and this also keeps the database healthy. When something happens, like corrupted storage, database or a sudden power loss on the server might affect the checkpoints between the mailbox database, logs, and server.
This means that all the transactions that occur in your Exchange setup are held in the log files and all the data which passed through the server to the database. What does this mean in regards of recovery? This means that if you have the transaction log, one can replay log file to reconstruct the entire Mailbox database from the transaction logs. Of course you would need all the log files, so a healthy backup must be in place.
However, if the log files are missing or can’t be replayed, you will need an Exchange Recovery software, such as Stellar Repair for Exchange. The software scans Exchange database and does not requires log files. It extracts the mailboxes from the database and lets you save them in PST format or you can import these mailboxes to a new or existing healthy database on Live Exchange in a few clicks.
With regards to recovery all starts with the Checkpoint file which can be found in the location of the database with the check extension. The checkpoint file keeps track of what has been committed to the database and not. If you are replaying the log files into your Exchange database and the checkpoint file does not exist, it will replay from the oldest available log file.
When a database has been successfully dismounted and in a consistent state with the log files and any pending transactions the result from the EseUtil the database state is in Healthy Shutdown and the Log required section is zero.
When you have a missing log file, this can be replayed into the database and commit the changes to the database. To do this one must run the EseUtil with the /ML parameter.
If there is a missing log file it will show like this
Missing log files: E00(000000100 – 000000110).log
While if all the log files are like below, then there is nothing wrong
Log files: D:\MBX01\Logs\E00(000000100 – 000000110).log
At this moment if you try to recover the database from a Dirty shutdown to a Healthy shutdown you might need to run the soft recovery which can be executed as below.
EseUtil /R E00 /l D:\MBX01\Logs /s D:\MBX01\Logs
The operation will fail with the below error
Log file: D:\MBX01\Logs\E00.log ERROR: Log damaged (unusable). Last Lgpos: (0xb8c2d,35,0). Error 501
Operation terminated with error -501 (JET_errLogFileCorrupt, Log file is corrupt) after 11602.418 seconds
Are you facing error -501 (JET_errLogFileCorrupt, Log file is corrupt)? Here is the short video to fix this error:
Now we need to check the database again using the EseUtil with the /MH parameter to identify the missing log file. Under the state, you will notice that log information.
State: Dirty Shutdown
Log Require 230-255 (0xe6-0xff) Log Committed: 0-255 (0x0-0xff) Log recovering: 255 (0xff
As you might see from the above there is no way to know exactly which log file is missing. There is a way to make the Exchange Server thing that the latest available log file in the sequence is the last available log file. You will need to rename the log file to E00.log which will make it the last available log file for the database.
Now you re-run the EseUtil with soft recovery you will get no error
EseUtil /R E00 /l D:\MBX01\Logs /s D:\MBX01\Logs
This time the soft recovery will give no issues and will run successfully. One has to note that the replay log file process will stop at the last available log file. All the newer transaction logs after the missing one will be discarded and lost. Once the process is done you can re-run the EseUtil with the /MH parameter and you see that the state is healthy. Now this takes a considerate amount of time and if you have a database of 20GB, it might take a while until it finishes. When it does you will be able to mount and access the database.
This can happen to anyone but you can also replay log files if all prerequisites exist which means all the transaction log files from the beginning. As always backup is most crucial part of the pre-requisites. If all fails and your database doesn’t change to a clean shutdown, you can always relay on third party Exchange EDB Recovery applications like Stellar Repair for Exchange to recover from any edition of Exchange EDB database, export to PST and other formats and export directly to a live Exchange Server or Office 365.