4.2 Focus: Exchange recovery technology

While there may be extreme catastrophic cases when the entire server must be rebuilt from scratch, most of our disaster-recovery scenarios will take place at the storage group or individual database level. In this next section, let’s take a look at how Exchange Server recovers its databases.

Exchange’s database engine is very powerful and provides high performance and robust service for storing semistructured data. However, the speed and ease with which Exchange can store user and business data are unimportant if the technology does not ensure recovery. Beginning with version 4.0, Exchange Server has also focused on providing a 7 24 platform that is highly recoverable. In this section, we will look at the technology behind Exchange Server’s promise of recoverability. We will expand this discussion further by looking at the best practices with which we can apply this technology.

4.2.1 Soft recovery

In many cases, Exchange Server is able to recover quietly when a server crashes and the contents of the database buffers in memory are lost. It does this by performing a soft recovery, a process that runs automatically when you try to start the information store after a failure or when you are mounting a database. Soft recovery uses the log files and database files on disk instead of tape backup to recover from a failure. The checkpoint file that I described in Chapter 3 is used to identify the oldest transaction not flushed to disk, and the log files and records are replayed from the generation indicated in the checkpoint forward. Any transactions in the log files that have not been committed are ignored. If your server crashes and the contents of memory are lost, the database file on disk is flagged as inconsistent in the database file header. The “database inconsistent” bit is set when the database is opened and remains set until it is closed and dismounted. Before you can restart Exchange Server and service users, the database must be made consistent again. Exchange Server uses soft recovery to simulate a clean shutdown by replaying pages from the log files on disk into the information store databases.

Here is how soft recovery works: First, the database engine (storage group instance) checks that the E0n. LOG file exists. Next, the database engine reads the checkpoint file to determine which log file to start replaying. If the checkpoint does not exist, all log files are scanned to determine if any committed transactions have not been written to the database. At the end of the operation, the database is effectively consistent again, and the Exchange Server information store can start normally. If, however, soft recovery does not work, there could be more serious problems with the system; you might be required to restore from backup.

4.2.2 Hard recovery

Restoring from an on-line backup is a process similar to soft recovery. I refer to this as hard recovery since the databases and/or log files must be restored from backup. Exchange Server makes sure that all of the files are put in the right place when using the backup APIs and brings the database up to a consistent state. In this scenario, when you restore data from tape backup, the restore process returns to disk all the files that were backed up. The information store checks the RESTORE.ENV file for the database (more on the RESTORE.ENV file later) and determines that the database has been restored from an on-line backup. With Exchange Server versions prior to Exchange 2000 SP2, the database engine then applies pages in the patch file (*.PAT) to the database files (property store—EDB Files). (Note: The requirement and usage of the patch file were eliminated for Exchange 2000 SP2 and beyond. Exchange Server 2003 does not use patch files during hard recovery.) The RESTORE.ENV file tells ESE where to start replaying the transaction logs. It does not check for E0n.LOG. ESE then replays the log files specified by the RESTORE.ENV and plays through any other logs in the current database directory. Using ESEUTIL with the /C switch allows you to modify how Exchange 2000/2003 uses the RESTORE.ENV file. The process of hard recovery is used when an Exchange server needs to be recovered from tape. In the next chapter, we will look at backup and restore fundamentals for Exchange 2000/2003.

Knowing exactly what makes your Exchange server and its supporting infrastructure fail is key to an Exchange administrator’s goal in ensuring a highly available messaging service. In this chapter, we looked at how you should approach Exchange failures and at the ways in which Exchange database problems can occur, as well as the best practices and tools for preventing, avoiding, and dealing with these failures. We also overviewed the other services upon which an Exchange deployment is dependent, as well as other potential root causes for Exchange failures. An Exchange administrator must be keenly aware of these issues and their potential for occurrence in order to successfully plan, design, and implement measures to protect against them.