Database corruption is a common and persistent issue with early versions of Microsoft Exchange. The latest versions of the software have attempted to address this issue but the environment is still occasionally prone to corruption. When this happens, administrators need to be aware of what their options are so that they can choose the most appropriate fix in order to get their communication environment up and running again as quickly as possible.
When no backups are available, Exchange administrators have a few options; inbuilt recovery features and third-party solutions. In this article we will take you through the process of using the Eseutil function in a few database recovery scenarios. We will also introduce you to an alternative third-party solution –that bypasses the need for using cmdlets.
Scenario1: Database does not mount even in a Clean Shutdown state
Sometimes a database won’t mount despite a consistency check showing it to be in a Clean Shutdown state. Run the following cmdlets in the Exchange Management Shell cmdlet to check the status of the database:
eseutil /mh (database file path)
The Clean Shutdown state shows that the database is healthy, but it cannot mount as it finds discrepancies with the log files. The solution here is simple—remove the log files and mount the database again. Exchange will create new log files while mounting the database.
Note: To note down the log file location, run:
Get-MailboxDatabase | Format-List Name,*path
Scenario 2: Database in a Dirty Shutdown state
Dirty Shutdown state indicates that the log files have some pending transactions to be written onto the database. As long as the database and log files are healthy, a simple soft recovery (technically, a replay of the log files in to the database) brings the database into a Clean Shutdown state.
To perform a soft recovery, run:
Eseutil /R Enn /L /s /d (path to database file)
Again check the status of the database, and mount it if it is in a Clean Shutdown state.
2.1: Database in a Dirty Shutdown State with missing log files
When the database is in a Dirty Shutdown state, and log files are missing or deleted, it can be repaired by a soft recovery. However, in this instance there is a high change of data loss. In such a situation, run:
Eseutil /R Enn /L (path to log files) /s /d (path to database file) /a
Now, check the status of the database and mount it if it is in Clean Shutdown state.
Note: To check the health of the transaction log files, run:
Eseutil \ml (log file path\Enn)
2.2: Database in a Dirty Shutdown state even after the soft recovery
If the database is in a Dirty Shutdown state after the soft recovery, it can be repaired by a hard recovery. To do a hard recovery, run:
Eseutil /P (database name)
During the recovery, you may experience severe levels of data loss as the corrupt pages will be removed completely.
And after the hard recovery, an offline defragmentation and an information store integrity check need to be performed. For offline defragmentation, run:
Eseutil /D (database name)
To perform an information store integrity check, run the following cmdlets and follow the instructions that appear on the screen:
Isinteg -s (server name ) -fix -test alltests
Using third-party recovery solutions to recover Exchange data
Exchange PowerShell cmdlets will allow you to recover data in most scenarios but they are a bit clumsy and can be time consuming to run. Recovery solutions, like Lepide Exchange Recovery Manager, have been specifically designed automate the process as much as possible and provide an easier way to recover all lost data as quickly as possible.
Lepide Exchange Recovery Manager helps you extract primary mailboxes, archive mailboxes and public folders from corrupt Exchange databases and restore your email communication system with minimal downtime. You can also use the backup extractor function to extract mailboxes and public folders from available backups.
Eseutil is a useful function when dealing with database corruption issues, including Dirty Shutdowns. It helps administrators perform soft recoveries as well as hard recoveries to repair corrupt databases. However, there will often be scenarios where using the Eseutil function will result in crippling data loss or simply won’t work altogether. In these scenarios it may make more sense to deploy a third-party solution, like Lepide Exchange Recovery Manager, that is specifically designed to recover complete databases with the minimal amount of effort.
Author and Credits: Lepide Software