In the 10 years I've been working with Microsoft Exchange Server, I've seen all kinds backup and restore problems. Here's a list of some of the most frequent problems and how to correct them.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
General failures when restoring an Exchange 2007 database
I've seen several real-life situations where a storage administrator attempts to restore an Exchange Server database, only to have the procedure fail because a policy is preventing the restore operation. To correct this problem, open the Exchange Management Console (in Exchange 2007) and navigate through the console tree to Server Configuration | Mailbox. Now, select the mailbox server that you are trying to perform the restoration on, and then select the individual database that you are trying to restore. Right click on the database, and choose the Properties command from the resulting shortcut menu. This will cause the console to display the database's properties sheet. Select the "This Database Can Be Overwritten by a Restore" check box, and click OK. You should now be able to perform the restoration.
The same principle also applies to Exchange Server 2003. If you need to restore an Exchange 2003 database, then open the Exchange System Manager and navigate through the console tree to Administrative Groups | your administrative group | Servers | your server | your storage group | your database. Now, right click on the database, and choose the Properties command from the resulting shortcut menu. When the database's properties sheet appears, go to the Database tab and select the "This Database Can Be Overwritten By a Restore" check box. Click OK, and you should be able to move forward with the restore.
Limited backup window
One of the biggest problems I've run into when it comes to backing up Exchange Server data is that the Exchange Server information store grows exponentially, but the window of time allotted for nightly backups stays the same or shrinks. There are at least two ways to deal with this problem.
One way of dealing with this problem is to keep the information store from growing. This means setting mailbox quotas, and then either archiving or deleting old messages. But this isn't always practical.
Perhaps a better way of dealing with this problem is to take advantage of Cluster Continuous Replication (CCR). CCR is an Exchange 2007 feature that allows you to maintain a copy of the information store databases on a separate server. Every time a transaction log file is completed, a copy of the transaction log is shipped to the other cluster node. This means that the cluster node has a copy of both the database and all of the transaction logs except for the one that is currently in use.
So what does this have to do with backing up Exchange Server? Well, you can't really use the cluster node as your only Exchange Server backup because it only offers you a limited amount of protection. CCR will protect you from a hard disk failure on the primary Exchange Server, but it won't protect you from things like log file corruption.
What some administrators have started doing is running the nightly backup against the backup cluster node rather than backing up the primary Exchange Server directly. That way, the backup can run without impacting the primary server's performance.
Moving a database to a new server
Traditionally, restoring an Exchange Server database to a new server after a catastrophic failure has always been a difficult endeavor. Exchange Server databases are server-specific, however, In Exchange 2007, Microsoft introduced something called database portability that allows an Exchange Server database to be restored to a different server more easily.
To restore a database to a different server, make sure that the database is in a clean shutdown state. Next, assuming you have all of the transaction logs that have accumulated since the backup, you will need to commit the transaction logs. You can do this by entering the ESEUTIL /R command, followed by the log file prefix for the storage group.
The next step in the process is to manually create an empty database on the target server. To do so, enter the following command using the Exchange Management Shell:
New-MailboxDatabase –StorageGroup <server_name?\<Storage_group_name> -Name <database_name>
Next, you must tell Exchange that it is OK for the newly created database to be overwritten during a restore operation. To do so, enter the following command into the Exchange Management Shell:
Set-MailboxDatabase <database_name> -AllowFileRestore:$True
Now, restore the database to the target server, and mount the database. Before your users will be able to access their mailboxes, you must tell Exchange that the users' mailboxes are on a new server. The easiest way to accomplish this is by entering the following command:
Recovering individual items
When Microsoft created SP1 for Exchange Server 2003, the concept of recovery storage groups was introduced. Recovery storage groups are used for recovering individual items from an Exchange Server backup. The basic concept behind using a recovery storage group in Exchange Server 2003 is that you can create a recovery storage group, restore your backup to the recovery storage group, and then use Exmerge to extract the desired items from the database.
If you have ever used Exmerge, then you know that it is a fairly complicated tool to use. Fortunately, Microsoft made the process of recovering individual items much easier. Recovery storage groups are still involved, but you no longer have to use Exmerge.
The first thing that you have to do is to create a recovery storage group. To do so, open the Exchange Management Console, and go to the Toolbox container. Now, click on the Database Recovery Management option. Exchange will now launch the Troubleshooting Assistant. Enter the name of your Exchange Server and the name of a domain controller into the space provided, and click Next. On the following screen, choose the Manage Recovery Storage Group option, and then click on the Create a Recovery Storage Group option. Now, select the storage group that you want to restore from, and click Next. Finally, choose the location of the original storage group files, and click the Create the Recovery Storage Group link.
Now, go ahead and restore your backup, but restore it to the recovery storage group. When the restore completes, open the Troubleshooting Assistant once again. This time, choose the Merge or Copy Mailbox Contents command. The Troubleshooting Assistant will now confirm that the mailbox database is mounted. Once that happens, click the Gather Merge Information link. On the next screen that you see, click the Perform Pre-Merge Tasks link. You will now have the opportunity to enter information about the items that you want to recover. You can recover data by mailbox name, date or even subject. Click the Perform Pre-Merge Tasks, and you will be taken to a screen that displays all of the data matching the criteria that you have specified. Select the data that you want to restore, and click the Perform Merge Actions link. The recovered data will be placed into a new folder named Recovered Data. From there, you can move it into a mailbox or into a PST file.
Restoring a deleted mailbox
When you delete an Exchange Server mailbox, that mailbox is not actually deleted for 30 days (by default anyway). Instead, the mailbox is disconnected from the user account that it was previously associated with. Restoring the mailbox involves reconnecting it to a user account. Typically, if you have deleted an Exchange mailbox though, the user account that the mailbox belongs to will also be deleted. When that happens, you will usually need to create a new user account and then connect the deleted mailbox to it.
Both Exchange Server 2003 and Exchange Server 2007 support reconnecting a disconnected mailbox, but the method of doing so is slightly different depending on which version of Exchange Server you are using.
To reconnect a deleted mailbox in Exchange Server 2007, open the Exchange Management Console, and navigate through the console tree to Recipient Configuration | Disconnected Mailbox. Next, click the Connect to Server link that's found in the console's Actions pane. This allows you to connect to the mailbox server that previously contained the mailbox. The console should now list all of the disconnected mailboxes. Select the mailbox that you want to connect, and then use the Connect Mailbox wizard to reconnect the mailbox. You can also perform the procedure through the Exchange Management Shell by running these commands:
If you need to reconnect an Exchange 2003 mailbox, and navigate through the console tree to Administrative Groups | your administrative group | Servers | your server | your storage group | the mailbox store containing the disconnected mailbox | Mailboxes. The console may display the disconnected mailbox with a red X. If so, then you can right click on it and choose the Reconnect command from the shortcut menu. Otherwise, right click on the Mailboxes container and select the Run Cleanup Agent command from the shortcut menu.
About the author: Brien M. Posey, MCSE, has previously received Microsoft's MVP award for Exchange Server, Windows Server and Internet Information Server (IIS). Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. You can visit Brien's personal website at www.brienposey.com.