Recovery from a corrupted database can be a tricky situation depending on the level of damage and how much data loss you wish to accept. In Exchange Server, we have the native command line tool called EseUtil that can check the status of a database and perform a quick recovery of data or hard recovery. With hard recovery, you must accept data loss as this process purges all corrupted data from the database. On the other hand, EseUtil can be used for restore processes where you restore an EDB file for Dialtone and recovery databases.
So, let’s say we have a database which is not mounting. First things first, since the database is not mounting, there must be some kind of corruption or missing data. There are some simple things that we need to check beforehand, such as:
- Track any changes on the server
- Check any updates which were installed
- Check storage
- Check antivirus that it is excluding the databases
- Check if the backup is application aware
If the above checklist read ok, we need to identity the status of a database. We need to understand what’s wrong with it as during the mount process in the GUI, we will get a generic error. So we need to understand what is wrong or what is preventing the database from coming up online.
To get this information, apart from looking at the Application Event Viewer, we need to use the EseUtil which will give us an indication on what’s wrong.
Open a command prompt as Administrator and Run
eseutil /mh <database file name>
The first thing to identity is the state of the database which is shown in the information given as below. If the state is in Healthy Shutdown, there shouldn’t be any issues and the database should mount but if you move out all the log files, and then try to mount again, it should work. If it is in Dirty Shutdown, the database will surely not mount and it’s an indication of corruption or missing log files. As we know, log files are a temporary storage for the database until these are committed in the database and if one of them is lost, data integrity is not successful.
Now, if your database is in Dirty Shutdown, you will also see that other line under it, which mentions the log file which is required. The first step is to check if the logs are healthy and if there is a problem with the logs. To do this, we need the ML prefix as below, with the log prefix which can be taken from the Log Required section of the report.
eseutil /ml "M:\mbx01\logs"
Here you will see the status of the logs and if all logs are healthy, you will get a message saying No damaged log files were found. If this is the case, we need to execute a soft recovery of the EseUtil using the /r parameter.
Eseutil /r e00 /l "M:\mbx01\logs" /d "M:\mbx01\database"
Once this process is done, you can mount the database. Of course you want to take in consideration the amount of time it will take depending on the damage or size of the database.
If you still get errors and the database remains with a Dirty Shutdown state, then we need to try to recover the database in hard recovery. It is important to note before doing this that this process will purge any data which EseUtil sees as damaged. You and the management will have to accept the data loss that this process will bring, irrespective of the damage.
To run a hard recovery, we need to use the eseutil/p parameter and apart from having enough storage to process the database, it could take a considerate amount of time. Once you start off, you will be reminded about the damage to confirm before proceeding.
Once done, you still cannot mount the database because we need to defragment the database using the New-MailboxRepairRequest if you have Exchange Server 2010 with SP1 or later versions. One thing to take in consideration is that once you run this process, you cannot stop it. If you decide to stop it anyway, it will be stopped abruptly causing even more damage to the database.
If all goes well, you will be able to mount the database. Some things to keep in mind about using the Eseutil is that the application is not a fool-proof system that will magically repair your database. It could be that your database is still not able to mount. Apart from this and depending on the size of the database and the level of damage, your users will not be able to receive, send or work with their mailboxes. In this day and age, stopping business for hours could be very damaging to a company.
On the other hand, you can use Stellar Repair for Exchange to do the job effortless and in much less time. The application can open corrupt EDB file from any Exchange Server Version. You can perform granular search with search filters. In this case when the database is damaged with no possible way to fix, one can easily create a new database and create mailboxes for the users so that business can continue… then use This EDB Recovery Software to import an EDB file directly into a live Exchange Server database with automatic mailbox match. This will work smoothly and the services will be restored in no time. Stellar Repair for Exchange can also export to PST and other file formats such as EML and PDF, and it can also import directly to an Office 365 tenant.