When Microsoft created Exchange Server 2010, it made major changes to the storage engine's architecture, including...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
eliminating storage groups. While this architectural change may seem irrelevant to the subject of single item recovery, the recovery storage group was the primary mechanism for single item recovery in Exchange Server 2007.
Since neither storage groups nor recovery storage groups exist in Exchange Server 2010, you have to use a recovery database. While the basic principles of single item recovery should not be completely unfamiliar to administrators with Exchange Server 2007 experience, there are some important differences.
Recovering a single item in Exchange Server 2007 involved creating a recovery storage group, then restoring an Exchange database into it. In Exchange Server 2010, you have to restore the backup and then create the recovery database.
But before doing this, you must check the database's properties sheet (Figure 1) and verify that the This Database Can Be Overwritten by a Restore check box is not selected. Otherwise, the restore process could potentially overwrite the production database.
The next step in the recovery process is to restore your database. The restoration process works differently depending on the backup software you're using. In the case of Windows Server Backup, you must instruct the recovery wizard to perform an application-level restore (Figure 2).
Next, you must choose to restore Exchange Server (Figure 3).
Instruct the Recovery Wizard where to restore the backup to. In Exchange Server 2007, if the Database Can Be Overwritten option is not enabled, instruct Windows Server Backup to restore the database to its original location. Then, Exchange Server will automatically redirect the restoration to a recovery storage group. But this works differently in Exchange Server 2010.
Create an empty folder on the server's hard drive -- Windows Server Backup won't create it for you -- then tell Windows Server Backup to restore Exchange Server to this folder (Figure 4).
Once the restoration process completes, the restored database and its transaction logs will be placed into the folder that you specified. Now you can create a recovery database. The trick is telling Exchange Server to use the restored files as the recovery database.
Exchange Server 2010 requires you to create a recovery database using Exchange Management Shell commands. So, open the EMS and enter the following command:
New-MailboxDatabase –Recovery –Name <database name> -Server <mailbox server name> -EdbFilePath "D:\Recovery\Database.edb" –LogFolderPath "D:\Recovery"
Creating a recovery database is similar to creating a mailbox database; both procedures are based on the New-MailboxDatabase command. The difference between the two processes is that you must specify the –Recovery switch to create a recovery database. Otherwise, Exchange will create a regular mailbox database. You also must name the database that you created and specify on which mailbox server to create the database.
The previous command includes an –EdbFilePath that you can use to specify the path to the database. You must provide Exchange Server with the path and filename for the database that you restored from backup. Likewise, the –LogFolderPath must point to the location of the transaction logs within your recovery folder.
Keep in mind that specifying the folder name alone isn't enough. You must provide the full path to the database and transaction log files. For example, I restored a backup to a folder named Recovery. However, the full path to my database is: C:\Recovery\C_\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database 1284628427.
If you look at Figure 5, you'll see that you received confirmation that the recovery database is using previously existing files. If you don't receive this confirmation, it means that you've entered the command incorrectly. If so, delete the recovery database and try again.
About the author: Brien M. Posey, MCSE, is a five-time recipient of Microsoft's Most Valuable Professional (MVP) award for his work with Exchange Server, Windows Server, Internet Information Services (IIS), and File Systems and Storage. Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at www.brienposey.com.
Do you have comments on this tip? Let us know.