First, let's verify my test user is able to access his mailbox while the database is mounted.
Next, let's delete the entire directory where the database and logs reside.
As a result, the database is dismounted and user cannot access OWA.
Now, let's start the recovery process!
Use the New-MailboxDatabase cmdlet to create a dial tone database, as shown in this example.
Use the Set-Mailbox cmdlet to rehome the user mailboxes hosted on the database being recovered (Mailbox Database) to the newly created dial-tone database (DTDB1), as shown in this example.
Notice if the database being recovered also hosts the arbitration mailboxes, you need to run the following Cmdlet to rehome the arbitration mailboxes as well:
Now let's mount the new dial-tone database.
Use the New-MailboxDatabase cmdlet with the -Recovery switch to create a Recovery Database
Caution: Do not mount the recovery database.
At this point, users should be able to access their email. They will have an empty mailbox without any history.
Depending on the backup program, you can either restore to an alternative location or restore directly to the recovery database.
After restore completes, run the following command to verify the state of the database:
Most likely the database will be in "Dirty Shutdown" state. Don't panic, this can be fixed! Pay attention to "Log Required" and "Log Committed". In my example, I am missing log E0200000X3D. If you are lucky enough to have all the missing log files, you can just run the following command to replay those log files into the database:
If you can't locate the missing log files, you will have to run ESEUTIL in repair mode (/p) to repair the database to bring it into Clean Shutdown state.
Refer to this for complete ESEUTIL usage.
Now, all you have to do is to make sure the database and log files exist under the recovery database directory and rename the database to be the name of the recovery database.
Mount the recovery database
The recovery database should mount successfully.
Now, we are ready to swap the Dial-tone database with the recovery database.
Dismount the dial-tone database and the recovery database. There will be a service interruption after you dismount the dial-tone database.
Set both databases to be restorable
Swap files in the dial-tone database directory with the files in the recovery database directory.
Rename dial-tone database to recovery database.
Rename recovery database to dial-tone database.
Now, mount both databases.
Service should be resumed and user will be able to access their mailbox again with all history.
Are we done yet? No, there is still data left in the current RDB database which was originally the dial-tone database. These data need to merged back to the current production database.
Use the Get-Mailbox and Restore-Mailbox cmdlets to export the data from the RDB and import it into the production database.
Congratulations, You have now successfully recovered the database!
P.S:
In a real world example, I didn't have to create a new database as the dial-tone. Instead I just renamed the failed database into something else and tried to mount it. The mounting process will create an empty database and you can just use this as your dial-tone. If you do this there is no need to rehome all the mailboxes.
No comments:
Post a Comment