In Part 1 of this series I explored what needs to be backed up for each of the different Exchange Server 2007 server roles.  In this post I will demonstrate a Mailbox Server failure and the recovery of the mailbox database from backup.

Backing up the Databases

The first thing we’ll need is a backup of the databases on the Mailbox Server.  For this demonstration I am using the built in NTBackup program for Windows Server 2003 to back up both of the storage groups for the server.

Mailbox Server Failure

The next step is to cause a server failure.  In the real world a potential point of failure for Mailbox Servers is the storage.  Typically databases will be located on SAN volumes, and a storage failure will cause the database to go offline.  To simulate this I simply remove the database file from its path on the test server.

Restoring the Database

Before beginning the database restore operation we must first prepare the database for recovery.  To do this open the properties of the Mailbox Database and tick the “This database can be overwritten by a restore” check box.

Using the NTBackup program we can now commence the restore of the Storage Group containing the Mailbox Database.

Mailbox Database restores will not automatically initiate a transaction log replay and then mount the database unless we specifically choose to.  This is for situations where the restore will involve a “full” backup set followed by a “differential” backup set, or followed by one or more “incremental” backup sets.  In this case we are only restoring a full backup set, so we can enable the “Last Restore Set” and “Mount Database after Restore” settings.  We must also specify a temporary path for log and patch files.

Once the restore operation is complete we can see that the Mailbox Database is now mounted and online again.

What Just Happened?

When the last restore set has been restored to the server it begins rebuilding the database using the recovered database and transaction log files from the backup set.  These transaction logs are replayed from the temporary location specified during the restore operation.  This achieves the outcome of restoring the database as at the time the backup was taken.  In the real world this would typically mean the previous night.  So what about all of the email that has been sent and received since then?

Again, in the real world Exchange Mailbox Server storage uses SAN volumes, or at the very least a disk layout that uses separate storage for the database and transaction logs.  This improves recoverability by ensuring that a failure of a single disk volume only causes the loss of the database or the transaction log, and not both at the same time.

In this demonstration that means that the transaction logs that have been generated by all of the current day’s email activity are still intact.  When the restore operation finishes with the data that came off the backup set it then begins to reply the transaction logs that still reside on the Exchange Mailbox Server.

This operation brings the database completely backed up to the current point in time, fully recovering all email items that were contained in it prior to the database failure.  Once this log replay operation is complete the database is mounted and made available to email users again.

How to Back Up and Restore Transport Servers

In the next part of this series I will demonstrate the process of backing up Hub Transport and Edge Transport servers and then recovering them from a failure.