If you would like to read the other parts of this article series please go to
- Eliminating Traditional Backups using native Exchange 2010 Functionality (Part 1)
- Eliminating Traditional Backups using native Exchange 2010 Functionality (Part 2)
- Eliminating Traditional Backups using native Exchange 2010 Functionality (Part 3)
Introduction
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
