Any changes in the Exchange mailboxes or database, such as sending or receiving emails, are first recorded in the transaction logs. These transaction logs are then queued and later committed to the Exchange mailbox database. This helps maintain the database integrity, prevent file locks, and improve the I/O performance of the server. All committed and non-committed transaction logs remain on the drive unless deleted. If you perform a VSS backup using an Exchange-aware backup utility, such as Windows Backup Server (WSB), all pending logs are committed to the database and deleted automatically thereafter to make space for newer logs.
However, if you accidentally or deliberately end up deleting the uncommitted transaction log files, you put the consistency of the database at risk. This can lead to integrity issues, Dirty Shutdown errors, and database corruption.
Importance of Log Files in Exchange Server Database Recovery
When you dismount the database via PowerShell or the Exchange Admin Center, the server commits all logs and gracefully shut down the database. The database state at this stage will be marked as Clean Shutdown.
On the other hand, when log files are uncommitted, missing, or corrupted, you cannot mount the Exchange database without log files. This could hinder the consistency of the Exchange database and disable the database mount. Due to this, the state of the database is marked as Dirty Shutdown.
The state of a database can be checked by using the native tool in Exchange Server called ESEUTIL. If you run the command eseutil /MH databasename in Exchange Management Shell or Command Prompt, you will see a lot of information about the database in the output. You must look for important information such as the State and Logs Required./databasename
The State will show you if the database is in a Clean or Dirty Shutdown state and the Logs Required will show you any missing/uncommitted or unreadable logs. This is the first indication of why the database is not mounting.
If your database cannot mount and is in a Dirty Shutdown state, don't panic as there are ways to recover Exchange database without log files.
Is It Possible to Recover a Database without Log Files?
ESEUTIL can help you recover the Exchange database without log files. However, you need to remember these two things:
- Take a backup of the database so that you have a copy of the current data, in case something goes wrong.
- Although ESEUTIL is a recovery tool, it's not 100% foolproof.
Also, Soft Recovery with EseUtil /r won’t work as the log files are missing. Thus, you need to execute Hard Recovery on the database using the eseutil /p parameter. But before running this command for Hard Recovery, consider some consequences, such as:
- It's not guaranteed that this will fix your database.
- You must accept data loss as Hard Recovery will purge any irrecoverable mailboxes or mail items from the database.
- If this fails, Microsoft will not provide support because when you run Hard Recovery, the database is hardcoded and marked.
If ESEUTIL fails, you may face the following error messages:
- Error -501 (JET_errLogFileCorrupt) – "Log File is Corrupt"
- Error -514 (JET_errBadLogVersion) – "Log file generated with different Exchange Server or edition"
- Error -515 (JET_errInvalidLogSequence) – "Any log file from the sequence is missing"
- Error -533 (JET_errCheckpointCorrupt) – "Checkpoint file is deleted or corrupt"
Case Study
Eseutil Failed? Worktrainers Ltd. Recovery from Critical Email Outages! - Explore the Full JourneySee how Worktrainers Ltd used Stellar Repair for Exchange
Video Tutorial to recover Exchange database without Log files
Safely Recover Exchange Database Without Log Files
By using Stellar Repair for Exchange, you can overcome the limitations and risks involved in the manual methods and recover any damaged, corrupt, or inconsistent Exchange database with complete integrity. The software supports all the Exchange Server versions, such as Exchange 5.5, 2000, 2003, 2007, 2010, 2013, 2016, and 2019.
With this software, you can select the damaged EDB files and export all recovered mailboxes to PST and other formats, such as EML, HTML, etc. In addition, you can export the EDB file directly to a live Exchange Server database or Office 365 tenant. All this is done in minimum time, with no administrative effort.
Follow the given steps, after you download and install the EDB repair software, to recover the Exchange database.
- Open the application and select the EDB file.
- Select the scan mode - Quick or Extensive.
- Once ready, you can browse the database and go through the mailboxes, journals, contact, calendar entries, and tasks.
- Click on the Save button, select PST, and then select the destination.
As mentioned, if you have an Exchange Server with a new database, you can simply click on live Exchange Server, and export all recovered mailboxes from the damaged database file to the new database on your server. It automatically matches the sources and destination mailboxes to export all mailboxes and items directly with minimal effort and time.
Conclusion
When you have a database on Exchange Server that cannot be mounted or shows a Dirty Shutdown state, it indicates an unhealthy Exchange database file. This usually occurs due to missing, uncommitted, or corrupt log file(s). If your database is in a Dirty Shutdown state or cannot be mounted, restart the server and check again. If you still can’t mount it or restore it, you may have to execute Hard Recovery using ESEUTIL. However, the process involves several risks and shortcomings and may lead to data loss. For hassle-free recovery of the Exchange database without a log file, use reliable and powerful Exchange recovery software, such as Stellar Repair for Exchange.
5 min read
