Eliminating Traditional Backups using native Exchange 2010 Functionality (Part 4)

by [Published on 15 June 2010 / Last Updated on 15 June 2010]

In this multi-part article, I’ll explain how you can eliminate your traditional disk or tape based backup solution using native Exchange 2010 functionality.

If you would like to read the other parts of this article series please go to


In part 3 of this multi-part article, we talked about why using lagged database copies might be of interest to your organization. In addition, I showed you how to configure lagged databases copies in a step by step fashion.

In this part 4 which, by the way is the last in this multi-part article, I’ll show you how you mailbox data from a specific point in time using a lagged database copy.

Simulating Mailbox Corruption

In order to have some exciting Exchange data to restore from the lagged database copy, let’s simulate a 3rd party application corrupted a significant amount of mailbox data. In this example, we will simply delete all 158 messages held in a subfolder to the Inbox named “Test”, but pretend that these 158 messages were corrupted by the 3rd party application.

So first let’s delete the items from the “Test” folder.

Figure 1: Deleting content of the Test folder

Then let’s delete them from the Deleted Items folder.

Figure 2: Deleting items from the Deleted Items folder

And finally let’s purge them from the Recoverable Items folder.

Figure 3: Purging the items from the Recoverabel Items folder

With that we now have a restore task in front of us.

Recovering Lost Mailbox Data from a Lagged Database Copy

The very first step we need to perform in order to restore data from a lagged database copy is to suspend replication to this particular database copy.

This is done using the following command:

Suspend-MailboxDatabaseCopy MDB01\E2K10EX10 –SuspendComment “Restore from point in time”

Figure 4: Suspending replication for the lagged database copy

Next it’s a good idea to take a non-Exchange aware snapshot of the volume on which the lagged database copy and the associated log stream is stored. This can be done with the Windows Server tool vssadmin.exe. In this lab environment, the database and associated log stream are stored on the E: drive, so we need to run the following command:

Vssadmin.exe create shadow /For=e:

Figure 5: Creating a snapshot of the database and log volume

When the snapshot has been taken, we can see more details about it using the following command:

Vssadmin.exe list shadows

Figure 6: Listing the VSS snapshot

Now is the time where we need to determine which log files need to be replayed into the lagged database copy. We can do this by looking at the time and date of the log files using Windows Explorer. We need to delete or move all log files that were generated when the accident occurred and any log files generated thereafter.

As mentioned, we can either delete the log files or move them to another folder. They will be reverted later on using the snapshot we took, so you could as well delete them.

Figure 7: Moving the relevant log files before replaying takes place

Next step is to delete the .chk file for the lagged database copy.

Figure 8: Deleting the .chk file

Currently the lagged database is in a “Dirty Shutdown” state, which can be verified by running the below command from the folder where the EDB file exists:

Eseutil /MH “MDB01.edb”

Figure 9: Lagged database copy currently in a dirty shutdown state

To bring the lagged database copy into a “Clean Shutdown” state, we need to replay the remaining log files by running:

Eseutil /r e02 /a

Figure 10: Replaying log files into the lagged database copy

Let’s run Eseutil /MH “MDB01.edb” again. We can see the database is now in a “Clean Shutdown” state, and ready for recovery purposes. So let’s copy it to a recovery LUN and continue the restore process from there. Doing so is a good best practice as you can revert the outstanding snapshot and resume replication right after the copy is completed.

Figure 11: Verifying the lagged database copy is in a clean shutdown state

To recover data from the lagged database, we need to mount it using a recovery database. So let’s create the recovery database using this command:

New-MailboxDatabase –Name “Recovery Database” –Server E2K10EX10 –EdbFilePath “C:\RDB\MDB01.edb” –LogFolderPath C:\RDB\ -Recovery

Figure 12: Creating a recovery database

Let’s mount the recovery database. This can be done using:

Mount-Database “Recovery Database”

Figure 13: Mounting the recovery database

Before we begin recovering data from the recovery database, let’s run the following command to see statistics for the mailbox database version from which we want to recover data:

Get-MailboxStatistics – Database “Recovery Database”

Figure 14: Listing mailboxes and item counts for each in the recovery database

Ok looks just fine, so we can initiate the restore:

Restore-Mailbox –Identity “Henrik Walther” –RecoveryDatabase “Recovery Database”

Figure 15: Restoring corrupted messages from the recovery database

Click “Yes” to the confirmation message. The missing messages are now merged into the production mailbox.

Figure 16: The corrupted mail items are now merged in the production mailbox

When the restore has completed, we can logon to the mailbox and see that we now have the “corrupted” messages back.

Figure 17: Messages restored successfully

Cleaning up and bringing the Lagged Database back to its orginal state

All there is to do now is to do some cleaning up, revert the outstanding snapshot and then resume replication.

Let’s first dismount the recovery database so that we can delete the MDB01.edb file we copied to the recovery LUN:

Dismount-Database “Recovery Database”

Figure 18: Dismounting the recovery database

Then let’s remove the recovery database from Exchange:

Remove-MailboxDatabase “Recovery Database”

Figure 19: Removing the recovery database from Exchange

Now delete the folder on the recovery LUN holding the EDB file.

In order to revert the outstanding snapshot, we need to first list the details for the snapshot using:

Vssadmin list shadows

Figure 20: Listing VSS snapshots

Take note of the shadow copy ID, then run this command:

Vssadmin revert shadow /Shadow={3711ecf7-a116-4734-bbe6-802536505598}

Figure 21: Reverting the snapshot

We can now see that the database copy, .chk file and the associated log stream has been reverted back to it’s original state.

Figure 22: .chk and original EDB file restored

We can now resume replication to the lagged database copy:

Resume-MailboxDatabaseCopy MDB01\E2k10EX10

Figure 23: Resuming replication from the lagged database copy

Also note that you need to run the following command to block the lagged database copy from being activated:

Suspend-MailboxDatabaseCopy –Identity MDB01\E2K10Ex10 -ActivationOnly

The restore task was a success and although it involves quite a few steps, it wasn’t really complex. And since this isn’t a thing you would need to do on a daily or weekly basis, this is a pretty good and just as important free point in time backup solution.

This concludes this multi-part article. I hope you learned something new along the way.

If you would like to read the other parts of this article series please go to

See Also

The Author — Henrik Walther

Henrik Walther avatar

Henrik Walther is a respected writer with special focus on Microsoft Exchange and Office 365 solutions. He works as a Principal Architect/Consultant on engagements of all sizes and complexity and have close to two decades of experience in the IT business.


Featured Links