Recovering a corrupted Exchange server is a complicated process – especially if, for any reason, you don’t have the required transaction log files to extract data from. In this scenario the database will enter an inconsistent state and become in-operative and it can be very difficult to recover. In this article we will take you through a couple of scenarios where recovery may be difficult – and hopefully give you the tools to overcome it.

When log files are unavailable

If the log files are not available, the corrupt database can be brought back to a consistent state through restoration using the ESEutil /p command.

The exact syntax used to recover the Exchange database without log files is:

Eseutil /p

It’s worth noting that this process could potentially lead to data loss if the Eseutil finds any corrupt pages, wrecked links between the tables or if any internal pages have to be deleted to make structural improvements within the database. This may require rebuilding the database through offline defragmentation and correcting B-tree arrangement which can sometimes difficult and time consuming task.

You will need to ensure that the computer has adequate disk space on the local drive for the interim repaired database. Users can keep 20 percent of the size of the database files for storing the temporary file that is being repaired. But the temporary file’s size may vary widely depending on the nature of the repair. Before running the command, make sure that the STM file is in the same folder as the MAPI database. If not, use a command line switch to find the path for the streaming database.

Mismatch of database and streaming files

In some cases, the database and the streaming files may fall out of sync due. This could be due to a crash or a failure of some sort. You can choose to ignore this problem, but if the streaming file and database are out of sync the repair will fail and all the data will be deleted from the streaming file. If you are positive that the streaming and database files are synced, you can choose to ignore a mismatch.

Users can run the following command to ignore a streaming file mismatch:

ESEUTIL /P priv1.edb /I

Streaming file is lost

If the streaming database is corrupt or lost, a repair is still possible, but significant data in the EDB file may be lost. If all of your users are MAPI clients, the data loss may be negligible. However, if users connect via POP3 or IMAP4, the data loss is likely to be significant.

When a database streaming file is lost or when a repair process cannot deal with the current streaming file, follow the below command to create a new streaming file:

ESEUTIL /P PRIV1.EDB /CREATESTM

After the repair, perform a full backup of the database as soon as possible – as the old backup may not have the latest data. After the database has been repaired, run a defrag utility “Esetuil /D” and “ISInteg –fix” to complete the process. Running these utilities will help you prevent any extra data loss.

Conclusion:

Recovering the Exchange Server database without logs is not a simple process. It requires an in-depth technical understanding of Esetuil commands and a large amount of time and patience. Thankfully, there are easier ways to go about it. Automated EDB recovery solutions,  help simplify data recovery through converting EDB files into Outlook PST formats when logs aren’t available.