It has become an adopted theory that for recovering an Exchange database, log files should be available. In this article, we will discuss the importance of transaction log file availability and what can be done to recover an Exchange database when log files are missing.

Hypothetical situation: A backup of the Exchange database (EDB) file is available, but there are no transaction logs. How do we bring the database back to a functional state? Will the database be restored with all the changes made to it?

The most basic concept to understand is that by the time the Exchange database is mounted in the Server, it is in a dirty state — the reason being the number of transactions that will take place in the database (i.e. sending or receiving messages, changes in the state of the email like read or unread, deleting or moving messages from a folder, etc). Therefore, if the backup is done while the database is mounted on the Server, it will definitely be in a dirty state (despite the type of backup). The requirement of log files for recovery depends on how the database is being backed up. 

If the backup is made while the database is online or a shadow copy is created using an application that's not compatible with Exchange, then along with the possibility of backup being in a dirty state, it may also be corrupt. If the database is copied without bringing it into an inactive state, then some of the transactions must be in process with the memory and not yet written to the database. Therefore, the backup created might have an inconsistent state.

If it is in a dirty state and log files are available, then uncommitted transactions can be rolled up and all changes done to the database will be reflected. However, if no log files are available, then the best option is to go through the repair process using the ESE utility /p switch. The ESEUTIL command can help you repair the Exchange Server database caused by a dirty shutdown.

If the backup is created using an Exchange-supported backup application while the database is online, then it will definitely be in a dirty state — but there is a lower chance that it will be corrupt. In this case, the backup can be restored and all uncommitted transactions will be replayed against it in order to bring the database back into a functional state. For this, it's mandatory that log files in the sequence are available to roll back the database.

To ensure that backup is not inconsistent, dismount the database before backing it up (i.e. create an offline backup). When the database is brought into an offline state, there are no uncommitted transactions and thus it is possible to recover Exchange database with missing log files. However, this option has a downside, too. First of all, you have to dismount the database, which means downtime for long hours. Also, transaction logs generated after backup creation will not be available, which means you may not get the most updated database backup in the operational state.

The requirement of log files in order to recover an Exchange database depends on what type of backup is created. If the backup is available but it is in a dirty state, then to get the most updated database back, it is important to have all log files in a healthy state. In a scenario where the database is in a dirty shutdown state, log files are missing, and you are not willing to go through the repair process, then you may want to look for software.