By Romeo Cavestany
What’s worse than having your Exchange system crash? Having your Exchange system crash and discovering in the midst of this disaster that you can’t restore it from your backup. After all, it’s not enough to have a backup system in place. You also need to test and validate that you can, indeed, use an Exchange backup to restore it.
As with many disaster recovery scenarios, prior planning and preparation for quick restoration of your databases can simplify the recovery process. Documenting the recovery steps can help reduce the duration of your outage.
In this recovery scenario for Exchange 2010 and later, we are going to explore the Exchange “dial tone recovery” process, whereby users are given temporary mailboxes for sending and receiving email while their original mailboxes are being restored or repaired.
What we recommend is that you first test to see if you can restore directly from your Exchange backup, and then test to see if you can successfully get through the more complicated process of also saving and restoring everything that took place since the backup was run. If you run your backups at midnight and your system crashes late-afternoon, you don’t want to lose a whole day’s worth of data!
Here is a suggested workflow for doing the more complex “dial tone recovery” process…
Optional Creation of Test Database
If you want to be cautious, your best bet is to run these validation tests using a test database. Doing this will completely isolate this validation process. However, taking this approach is not a requirement. Another option is to use your actual Exchange backup production database. If this is your preference, just skip down to Phase 1.
For the test database approach, here’s what you need to do before you begin the validation process:
- Create a test database (complete with users and email and calendar data).
- New-Mailboxdatabase -name <test database name> -server <server name> -edbfilepath <DBFolder\db.edb> -logfolderpath <DBFolder\>
New-mailboxdatabase -name TestDB1 -server MailboxServer1 -edbfilepath D:\TestMDB\TestDB1.edb -logfolderpath D:\TestMDB\
- Send a test message to a test account’s mailbox on this database, as a reference point for validating the restore later.
- Run a backup of the test database.
Phase I: Provide temporary email functionality
- Create a new Dial Tone database. Use the New-MailboxDatabase command without the -Recovery parameter to create a new Dial Tone database:
- New-Mailboxdatabase -name <dial tone databasename> -server <servername> -edbfilepath <Dbpathname\db.edb> -logfolderpath <Dbpathname\>
New-Mailboxdatabase -name DialToneDB1 -server MailboxServer1 -edbfilepath D:\DialTone\DialToneDB1.edb -logfolderpath D:\DialTone\
- Simulate a disaster by dismounting the test or production database.
- Dismount-Database TestDB1
- Rehome the user mailboxes hosted on the dismounted (corrupted) database to the new Dial Tone database.
- Get-Mailbox -Database TestDB1 | Set-mailbox -database DialToneDB1
- Mount the Dial Tone database so that users can access the database and send and receive messages.
- Mount-Database –Identity DialToneDB1
- Test connectivity to the Dial Tone Database. At this point the system should be using your Dial Tone database as the production database. Validate that Outlook clients can connect to this Dial Tone database to send and receive messages. Note that at this point users will not have access to any prior stored messages or calendar items. The idea here is to provide the ability to send and receive new messages while you continue to work on the overall recovery.
Phase II: Create a recovery database
To simulate a corrupted database, we are going to restore from the Exchange backup in order to show the recovery steps and commands in this scenario.
- Create a Recovery database (RDB).
- New-mailboxdatabase -recovery -name <databasename> -server <servername> -edbfilepath <Dbpathname\db.edb> -logfolderpath <Dbpathname\>
New-MailboxDatabase -recovery -name RDB1 -server MailboxServer1 -edbfilepath D:\Recovery\RDB1.edb -logfolderpath D:\Recovery\
- Prepare the Recovery database to receive the backup data. Go to the Recovery database’s Properties page in Exchange. On the “Maintenance” tab, check the box for “This database can be overwritten by a restore”. Doing this is critical for restoring directly from the backup into the database. If this box is not checked, the restore process may not work.
- Restore the test or Exchange backup production database and log files from the test or production backup to the Recovery folder.
- Check for clean shutdown state. After the data is copied to the RDB, but before mounting the Recovery database, check if the restored Recovery database is in a clean state. Use the eseutil tool to check the health of database, and to recover the database into a clean state if necessary.This first command will tell you if the database is in a dirty shutdown state. Run this command against the restored database in the Recovery folder:
- eseutil /mh <databasename.edb>
Example: D:\Recovery\eseutil /mh TESDB1.edb
If the restored database is in a dirty shutdown state, run this command to repair it. Please note that the eseutil repair tool has a range of helpful switches. Should you find yourself looking at a different error, please consult the Exchange Server Database Utility Guide at Microsoft Technet.
- Eseutil /r <logfile base name> /d <log file directory>
To determine the log file base name, open the Recovery folder in File Explorer and look for a file with an extension of .chk.
In this example, the log file base name is E1A.
Example: D:\Recovery\eseutil /r E1A /d D:\Recovery
- Rename, mount, dismount. After repairing the backup file in Step #9, rename it to edb. Mount the RDB database, and then dismount it.
- Rename D:\Recovery\TestDB1.edb D:\Recovery\RDB1.edb
- Mount-Database –Identity RDB1 | Dismount-Database –Identity RDB1
- Move the RDB database and log files. After the RDB is dismounted, move the database and log files associated with the RDB from the Recovery folder to a temporary (safe) location. Let’s call this new folder “Safe.” This is done in preparation for swapping the recovered database with the Dial Tone database. In our example, we will create a folder called D:\Safe and move all files from the Recovery folder to this folder.
- Move D:\Recovery\*.* D:\Safe
- Dismount the Dial Tone database. This will disconnect end users that are hosted on the Dial Tone database.
- Move the database and logs files from the Dial Tone folder into the Recovery folder. Remember, this folder was emptied out in step #11, and is now available to receive the Dial Tone database’s information. After moving the Dial Tone files, rename the DialToneDB1.edb file to RDB1.edb, as the folder is associated with the RDB database.
- Move D:\DialTone\*.* D:\Recovery
- Rename D:\Recovery\DialToneDB1.edb D:\Recovery\RDB1.edb
- Move the database and log files from the Safe location into the Dial Tone database, rename the RDB1.edb file to DialToneDB1.edb, and then mount the Dial Tone database. At this point, the Dial Tone database now contains all messages from the Exchange backup.
- Move D:\Safe\*.* D:\DialTone
- Rename D:\DialTone\RDB1.edb D:\DialTone\DialToneDB1.edb
- Mount-Database –Identity DialToneDB1
- Mount the RDB. Remember, at this point, the RDB database contains the database and log files from the original Dial Tone folder.
- Mount-Database –Identity RDB1
- Export the data from the RDB and import it into the Dial Tone database. Keep in mind that the database and logs file have been swapped. This will merge the backup data with the data from all of the messages from the temporary mailboxes that were provided during the period that the Dial Tone database was being used.
- Get-Mailbox –database DialToneDB1 | Restore-Mailbox –recoverydatabase RDB1
- Validate the merged data. At this point, users should be able to see all of their messages. In Outlook, using your account, check if you can see the messages that were captured by the backup, as well as the messages created in the DialToneDB.
- Dismount and remove the RDB after the export process is complete. After validating the merged data, you can go ahead and remove the recovery database.
- Dismount-Database RDB1 | Remove-MailboxDatabase RDB1
At this point the validation test is complete.
If this were an actual recovery situation, and you were able to repair the production database with eseutil, you would now merge the data between the production database and the dial tone database. Since our objective here is to show how to validate the integrity of your database backup, we’ve decided to use the approach described above so you can isolate the validation process and not risk your production database. Additionally, by providing these repeatable steps, you will be able to gain a better understanding of the recovery process through practice.
As the Boy Scout motto says, you need to Be Prepared. Don’t wait for disaster to strike. It is industry best practice that at least once every six months you should test and validate that your Exchange backup and restore protocol works. Need help doing this? Give us a call! As Microsoft Gold Certified Partners with over 20 years of experience working with Microsoft products, we have the expertise to help you get the job done.