In my last article we discussed how to benefit from the built-in windows server backup feature of Windows 2008 and 2008 R2 and perform healthy backups of your Microsoft Exchange databases for free, without the need for any 3rd party tool. Today, we are going to go over the restore process by looking at two different situations; the first one is when we have experienced a complete loss of one database, and the second is when we need to recover just a single item from a mailbox.

This will be a very practical, step-by-step guide and, as before, the screenshots in this article are taken from a Exchange 2010 DAG running on Windows 2008 R2. My goal is get you up and running with this process as fast as possible, without any diversions.

Full mailbox database recovery

We will start by taking a look at the mailbox of user2; as you can see from figure 1, the latest email was received at 3:06pm, which is just after the backup was taken:

Figure 1 : User2’s mailbox before the crash

I will now crash the database where user2’s mailbox resides by simply deleting its .edb file. I should clarify that I have only deleted the .edb file and not any log files, as these will be used later on to recover data that was sent/received between the backup and the crash (like the most recent email mentioned above). We now have a typical scenario where the database has been “corrupted”, and all we have left is the latest backup (taken at 3:01pm in our case), and the log files covering the time window between the backup and the crash (which was at 11:46pm). So, how do we recover from this?

To initiate the recovery process, run Windows Server Backup and pick “Recover” from the action pane, as shown in figure 2 below:

Figure 2 : Select Recover from the Windows Server Backup

In the next screen you are asked to decide where the backup files are located. This one is a bit misleading, as our backup files are stored on a remote computer, but since the backup was taken on the same machine we are restoring to, you can just keep “This server (Servername)” selected, as shown in figure 3:

Figure 3 : Select backup files location

On the following calendar page, you will be presented with all available backups, and you simply need to pick which one you want to restore from. The dates when backups were taken will be in bold, and in our case the only backups available are on June 4th; in addition, if there are multiple backups on the same date, they will all be available through the “time” drop-down menu to the right of the calendar. The backup which I want to restore from is the one take at 3:01pm, so I will select it, and you should note how the correct location is automatically retrieved.

Figure 4 : Select Backup Date

I would like to spend some time analyzing the next screen (shown in figure 5); notice how the “Applications” option is dimmed? The reason behind this is because the backup was taken at the folder level, and not at the volume level (please refer to the backup article for more information about this).

Figure 5 : Select Recovery Type “Applications” disabled

If, on the other hand, you’d selected the whole volume on which your database resides while taking your backup, then the “Applications” option would be enabled (as shown in figure 6), and this is the option which you would be selecting.:

Figure 6 : Select Recovery Type “Applications” enabled

However, since “Applications” is dimmed in our case, we will select “Files and folders“, and then select the folder containing the corrupted .edb database which we need to recover.

Figure 7 : Select Items to recover

Since we completely lost our database, we will restore it to its original location and overwrite any existing file with the recovered versions…

Figure 8 : Specify Recovery Options “Original Location”

… and now we just need to wait for the restore to finish:

Figure 9 : Recovery Progress

Once the restore process is done, taking a look at the original location of the database will reveal that the .edb file is back in place, and all the log files generated between the backup and the crash are still there.

Figure 10 : Database & Log files after recovery

If we are curious enough to check the status of the database that was just recovered, we run this command:

… And we will notice that it is in a “Dirty Shutdown” state, as shown in figure 12 below; this is actually good news, since it will give us the chance to replay the log files up till the crash time, and so not lose data.

Figure 11 : Recovered database in “Dirty Shutdown” state

I’m not going to go into more detail about the eseutil.exe tool, as this article is aimed at getting results as fast as possible. If you’d like to know more, then Jaap Wesselius has an article on MSExchange.org which explains the tool in detail with regards to Exchange Server 2010. Mounting the just-restored database will generate a lot of “Event: 301” in the application log, each corresponding to a log file being replayed, after which the database will successfully mount. There is nothing for you to do at this stage, as the replay will happen automatically:

Figure 12 : Event Log during log replay

Finally, looking at the mailbox of User2 again after the restore process, we can see a complete recovery of all the data. Even the email that was received after the backup was recovered, thanks to the log replay.

Figure 13 : user2 mailbox after recovery

Emails recovery

Another possible situation I’d like to cover in this article is the case when you need to recover a single mailbox, or even a single item in a mailbox. It sounds like a tall order, but it’s really not that hard, as we’re about to see. To create an appropriate scenario, I’ll start by deleting the first email from user2’s mailbox, so that it now looks like this:

Figure 14 : Deleting emails from user2 mailbox

Since the recovery process is fairly similar to the steps for a full recover, I will fast-forward to the point when we are asked to specify the recovery options. Since the actual database is still operational and mounted this time, we do not want to restore to the original location; instead I will specify c:\recover as alternate location (as you can see below), and then proceed normally with the recovery process.

Figure 15 : Specify Recovery Options “Another Location”

Just like before, running the eseutil/mh command against the newly recovered database will show it to be in a dirty shutdown state (figure 12). However, simply mounting the database as before will not work, as it needs to be brought to a “Clean Shutdown” state before it can be used as a mailbox recovery database. This is confirmed by the warning which Exchange returns when you try to create the recovery database using the PowerShell command:

Note:
Recovery databases cannot be created using Exchange Management Console.

Figure 16 : Creating the recovery database

This is by no means a significant hurdle, because the database is brought to a clean shutdown state simply by running:

This will perform a soft recovery of the database, and prepare it for mounting:

Figure 17 : Bringing the database to a “Clean Shutdown” state

Running eseutil /mh “Mailbox Database.edb” one last time will reveal that the database is now in a “Clean Shutdown” state, and ready to be mounted:

Figure 18 : Checking the database state after eseutil /R

It is now safe to mount the database using the “Mount-Database recdb” PowerShell command (“recdb” is just what I’ve named my recovery database – adjust as appropriate to your environment), and then recover user2’s mailbox by running:

This is a very simple example of the Restore-Mailbox command, which simply restores all the data for User2’s mailbox from the “recdb” database:

Figure 19 : Restoring user2 mailbox

As you can see in figure 20, the first email was recovered seamlessly. Bear in mind that this command can only use a disconnected mailbox as a data source, and a connected mailbox as a data target. In this case I’ve restored Use2’s entire mailbox, but there are a host of command line switches you can use to limit the scope of the data you are recovering, and retrieve specific items. I’ve just covered the bare, practical steps for this process, but if you’d like a deeper understanding of the Restore-Mailbox options and switches, please refer to this TechNet article. In addition, the steps involved to recover a single mailbox are covered here.

Figure 20 : Recovered emails

Conclusion

Over the course of this two-part article, we have looked at the options available to backup and restore Microsoft Exchange 2007/2010 using the native Windows Server Backup tool. We went through the various steps needed in order to backup your mailbox databases, as well as restoring them to their original location or to an alternate location for use as a recovery database.

These have both been fairly quick step-by-step guides, designed to help you get results as quickly as possible. If you’ve only read this second part of the article and want to know more about the backup procedures, I invite you to read part 1 to get a complete picture.