Exchange Server Mailbox Database is the core for any business as it holds all the emails, data containing emails, contact, notes, calendar entries, public folders and more. All these are contained in several files but mainly in the EDB file. There is a misconception that all you need is to keep and backup the EDB. However, the EDB alone is not enough. Although one might see them as just log files, transaction logs are also a crucial part of having a healthy and consistent database. If you have a missing log file or a damaged log file, which has not been committed to the database, will cause issues in your database. For instance, the database will not be able to mount, thus leaving your users furious and unable to work.
If all the users access the database, it becomes slow with chances of getting corrupted. With Server Memory and transaction logs as a buffer, access to the database will be faster and safe. When data is put in transaction logs and a backup is taken, all the transaction logs are committed to the database.
Taking a proper backup is important as it will commit and purge the transaction logs. Using a normal backup software which is not application-aware, only backup a file system.It is not ideal for an Exchange Server. Apart from unable to backup the database properly, it might also not backup the EDB file, and due to which it might be locked or damage the database itself. If backup doesn't run properly, the transaction logs will keep accumulating until the hard drive is full. If the drive is full, you might end up with a corrupted database.
As you can see, logs play an important role in an Exchange Server. Therefore, it's important to have ample storage space and backup the database with an application-aware software to ensure a healthy and safe backup of your precious data. You can take daily or mid-day backup of the Exchange Server, but accidents and disasters can happen at any time. Being prepared for such occurrenceswith a contingency plan or a disaster recovery plan which is tested on a yearly basis, will bring peace of mind as you know that in case of disaster, people would know how and what to do to restore the services in the minimal time possible.
When you unmount the database via PowerShell or the Exchange Admin Console, it will commit all logs and gracefully shut down the database. The database at this stage will be marked as clean shutdown state.
On the other hand, when log files are missing or corrupted, your database will not be able to mount. The database or logs may get damaged due to a third party tool like an antivirus which is not Exchange Server safe, a faulty Windows update, not compatible backup software, sudden loss of power or any other reason. This could hinder the consistency of your database, and it will not mount. Due to this, the state of the database is marked as Dirty Shutdown state.
The state of a database can be checked by using the native tool in Exchange Server called ESEUTIL. When running the below given cmdlet, you will get a lot of information about the database. You must look for important information such as the State and Logs Required.
The State will show you if the database is in clean or dirty shutdown state and the Logs Required will show you any missing or unreadable logs. This is the first indication of why the database is not mounting.
If your database cannot mount and it's in Dirty Shutdown, don't panic as there are ways to recover from such a situation.
If your log files are mostly of today's backup and not part of yesterday's backup, you need to recover the database in a clean state. ESEUTIL will help to recover the database. However, two things we need to mention here are:
To start off, run a soft recovery of the database by using the following ESEUTIL/r parameter:
eseutil /r E06 /lL:\logs /d M:\DB01
When this is complete, you need to check if the database is in CleanShutdown. If yes, you can go ahead and just mount the database. If not, a restore will be out of the question and the only choice is to try with a hard recovery. This can be executed by using the eseutil/p parameter. Before running this command, you might need to consider some facts, such as:
If Eseutil fails, you may face the following error messages:
By using Stellar Repair for Exchange, you will be able to recover any Exchange database. The software supports all the Exchange server versions–from 5.5 to the latest 2019. You can add an EDB file to the application and export it to PST and other formats such as EML, HTML, etc. In addition, you can export an EDB file directly to a live Exchange Server database or Office 365 tenant. All this is done in the minimum time, with no administrative effort.
Follow the given steps after you download and install the best EDB repair software.
As mentioned, if you have an Exchange Server new database, you can simply click on Live Exchange Server and your mailboxes will be automatically matched and imported directly.
This article explains to get back all their old mail and restore the original mail from crashed Exchange server. Explore all technical know-how or the right tools in hand to have a quick recovery with minimal downtime, for the Exchange Admins.
Experts recommend to use Eseutil/mh command to identify Exchange database state. If your database in ‘Dirty Shutdown State’ then use eseutil/mh commands to change the database state to ‘Clean Shutdown’.
Run ESEUTIL /P commands to complete Exchange database hard repair process using . ESEUTIL /P – repair corrupt or damaged exchange database EDB files smoothly.
how you can repair a PST file after a changes with MDBVU32. This free method also supports Windows 10 and Outlook 2016.
Useful tips to fix file File Level Exchange Server Database Error 1018, 1019 and 1022. It is applicable for all Exchange Server versions 2016 / 2013.