How to Recover Exchange Database Without Log Files?

 

The Exchange database is a store house of information. Thousands of user mailboxes containing emails, contacts, notes, calendar items and more reside within Exchange EDB files and the responsibility to keep them safe lies with the database administrator. A single mishap could lead to loss of critical data and incur huge losses for any organization. Thus, proper backups are maintained to minimize risks as much as possible and make sure the server can be brought back to its working state quickly.

The simplest way to recover a crashed server is by recovering the database from a recent backup. And when it comes to recovering from backup, Exchange transaction log files play an important role. This article sheds light on this role of the log files and discusses how an Exchange administrator should restore user mailboxes in case the log files are missing / unavailable.

Why are log files important?

In many respects, the Exchange server can be viewed as a transaction based emailing system. A transaction is any set of operations performed against the database that involves inserting / updating / deleting data while making sure the ACID properties of the database remain intact. Each transaction is recorded within database log files to keep a proper track of every change that affects the database. This is done to make sure that if anything goes wrong, previous transactions can be reversed (rolled back) and the database can be restored to its working state.

Transaction log files record entries up to the second. That's why these files are of extreme importance in time of failures. Exchange backup and recovery depends heavily on these log files. Each transaction is first written to log file on the hard disk and then they are committed from the log files to the database on the server. This short gap provides DBAs the window to copy log files to other disks as backups so that in event of a crisis, even if the database main files are affected, the log files remain safe. As long as the database is available and healthy, the log files can be replayed to recover data up to the last committed transaction.

Now that we've established the importance of log files, let’s move to the scenario wherein they are unavailable. How does the administrator recover Exchange database in that case?

Inconsistent Vs Consistent Database

Database consistency is one of the core elements of ACID properties. A database must always be in a consistent state to be regarded as healthy. To ensure that the database is consistent, all transactions within the log files must be committed to the database before it is shut down. If this is done, the database is regarded as detached from the log files and the state is said to be a clean-shutdown state.

Alternatively, if some transactions within log files have still not been committed to the database when the server shuts down accidentally (due to a sudden power surge or hardware problem maybe), the database remains attached with the log files. As a result, the pages yet to be written to the server are marked as "Dirty". As long as dirty pages exist within the database, it is regarded as inconsistent and this state is known as dirty-shutdown state.

To verify the state of the database at any given time, the ESEUTIL command can be used as follows: eseutil /mh Restore & Recovery of the Database

Before moving on to the main topic of the article, it is important that we establish the difference between the terms Restore and Recovery. While both these terms are often used interchangeably, they are slightly different. Restore involves putting the database log files back to their original location on the Exchange server whereas Recovery involves replaying log files into restored database.

This again states how crucial log files are in the database "recovery" process.

Recovering Exchange database without Log files

Recovering the database with log files is quite straightforward using the Eseutil command. However, if the log files are missing / unavailable, there are two paths the recovery process can take:

1. The replay process will fail entirely

2. The recovery process will abort with errors

Common errors encountered in such case include:
  • Error -501 (JET_errLogFileCorrupt) – “Log File is Corrupt”
  • Error -514 (JET_errBadLogVersion) – “Log file generated with different Exchange Server or edition”
  • Error -515 (JET_errInvalidLogSequence) – “Any log file from the sequence is missing”
  • Error -533 (JET_errCheckpointCorrupt) – “Checkpoint file is deleted or corrupt”

The power of the ESEUTIL command is that it can be used to repair the database (bring it to consistent state) with or without log files. Without log files, this command can be used with /p switch to perform the task as follows: eseutil /p

Though it will work, the process might lead to data loss if ESEUtil finds corrupt databases pages or broken links between tables or if internal pages need to be deleted for structure improvement. As a result, you might need to rebuild the database using offline defragmentation and then correct the database’s B-tree structure. All in all, this could prove to be very time taking.

Therefore, to avoid these hurdles, we recommend using professional EDB repair software. These utility repairs corrupted / damaged EDB files to recover all inaccessible mailboxes by converting EDB data into MS Outlook compatible PST format. Additionally, it allows you to store recovered data as MSG, EML, HTML, RTF and PDF Files. It even facilitates exporting recovered mailboxes to Live Exchange Server and Office 365. With an easy to follow interactive GUI and compatibility with MS Exchange Server 2016 / 2013 / 2010 / 2007 / 2003 / 2000 and 5.5, this third-party application would be your best chance to bring the database back to consistent state without any data loss.

Stellar Phoenix & Stellar Data Recovery are Registered Trademarks of Stellar Information Technology Pvt. Ltd.
© Copyright 2017 Stellar Information Technology Pvt. Ltd. All Trademarks Acknowledged.