From time to time in an Exchange environment, we will have a situation where we will need to recover a corrupted or failed Exchange database. There is nothing more terrifying, and nothing that leaves you more exposed as an Exchange admin that this type of recovery.
There are various backup applications available, but essentially they all do the same function. There are some very important differences between VSS and Streaming backups, but for the sake of this article, the restore functions the same.
Here is the scenario:
You have a database that is backed up on Monday night. Come Thursday morning, the database has been completely corrupted beyond repair, and you need to restore from your full backup on Monday night. However, you want all the data that occurred from that backup, to Thursday morning. After all, if you tell your CEO that he’s loosing two days of emails, he’s telling you your losing your job.
That is the beauty of Exchange transaction logs, they allow you to "roll forward" up to the point that there was database corruption. Most backup software can do this automatically for you, by telling it that the backup your recovering is the "Last Backup Set", or you can run it manually by using the ESEUTIL.
Here it is, on my test server I have a database on my test server:
I have a database, named Schneider.com MDB1. Currently the database is brand new, with one mailbox in it, so the database is effectively blank. We will take a backup of it in its "blank" state, and then add data to it, restore the blank DB from restore and roll it forward! We will use Windows Backup to backup our entire server as below to the desktop:
Now that we have a backup of the DB, lets add some data to the DB. I’ve done this by simply importing a 500 MB PST to a mailbox on the Schneider.com
Now, lets simulate a failure by dismounting the DB.
So, our database is dismounted, simulating a corrupt database. Now, lets restore the old blank database.
Normally, when you restore a database in Exchange 2003, or 2007, you first create a Recovery Storage Group. In order to restore a backup over an existing DB, you need to select a simple check box. Right click the Database->Properties->Database Tab and select the check box “This database can be overwritten by a restore”:
Otherwise, if we tried to restore the database it would force us to go into a RSG. Now, lets recover the database. Notice in the restore window, it is asking for a temporary location for log and patch files, as well as the “Last Restore Set” checkbox:
Lets leave the Last Restore Set unchecked, because we want to run ESEUTIL ourselves. Choose a temp location and hit OK to start the Recovery.
Once the restore is finished, we have several things to note. First, the database has been restored to its previous state, and if we note, its quite small.
Next, the C:\Recovery folder. Here we note there is a transaction log, and the Restore.env file. This file acts as a checkpoint file for the recovered database to determine where it should start playing back transaction log files from:
Last, we note the transaction logs for this Storage Group, that seems to indicate a decent amount of activity since the last backup, this are the files we will use to play back the missing data into the DB:
So, we now have our database restored, so its time to run ESEUTIL! Eseutil is located by default in C:\Program Files\Exchsrvr\bin, so navigate there in a command prompt. The first thing we want to note is the condition of the restored database. Run the command eseutil /mh c:\dbfolder\nameofdb.edb or in my case
eseutil /mh "C:\exchange db\schneider.com\schneider.com mdb1.edb"
This is known as a header dump, and it will indicate the condition of the database:
As you can see we are in a “Dirty Shutdown” condition, which means the DB knows that its missing log files, the problem is it has no idea which ones. We tell it which ones by using eseutil and pointing it at the restore.env file we recovered earlier. If we tried to restart the databse now, we would recieve an error because our DB is not in a clean shutdown state.
We now want to perform a “hard replay” using the command eseutil /cc c:\path to restore.env or in my case eseutil /cc “c:\recovery\schneider.com”
Now if we do a header dump again, we see that our DB is in the Clean Shutdown state:
Note also that the EDB file is now returned to a normal size:
Now mount the store, and you are finished! Enjoy!