Just because database availability groups go a long way toward protecting Exchange 2010 mailbox databases from disk failures doesn’t mean they can replace regular backups. And while mailbox databases are susceptible to disk failures, writing corrupt data to them is just as damaging.
You can’t use DAGs to avoid corrupt data. If corrupt data is written to a mailbox database, then that data would also be replicated to DAG members hosting database replicas. For this problem, Microsoft recommends using lagged database copies.
What are lagged database copies?
Database replicas have no replay lag time; when transaction logs are replicated to a database copy, they are replayed into the database immediately. A lagged database copy is a mailbox database replica with a replay lag time value greater than zero. This means that transaction logs aren’t replayed into the database immediately. If corrupt data infects a mailbox database, but you discover it before transaction logs are replayed onto lagged database copies, you can use lagged database copies to roll the entire mailbox database back to a previous point in time.
Even though the idea of lagged database copies works, the technology itself isn’t exactly ready for prime time. Activating a lagged mailbox database copy is a complicated procedure with great potential for data loss. Additionally, lagged database copies only work if you discover the corruption before log files are replayed on the lagged database copy. After you detect the corruption, you should suspend the mailbox database copy process to prevent additional log files from being copied to the lagged server. This will also halt the log file replay process.
What’s wrong with lagged database copies?
Microsoft recommends backing up the server that's hosting the lagged database copy after the mailbox database copy process has been suspended. The tricky part of this is the next step. After you create the backup, you must determine exactly when the mailbox database became corrupt.
The tricky part is that Microsoft doesn’t provide any tools to help figure that out. You have to guess when the problem occurred and then delete the checkpoint file on the lagged database copy. You should also delete the accumulated transaction logs up to the point in time you believe the problem began.
This technique leaves a lot to chance; it’s nearly impossible to guess the exact date and time that transaction logs first became corrupted. And an incorrect guess can have serious consequences.
If you guess a date and time that precedes the database corruption, you'll successfully eliminate the problem. However, you’ll also delete legitimate and potentially mission-critical data. If you choose a date and time period after the corruption occurred, the recovery process will add the corrupted data to your clean lagged mailbox copy. In this case, your only recovery option is to restore a backup.
I recommend you activate a lagged mailbox database copy only as a last resort. It’s better to simply restore a backup. Even though this requires some guesswork, you can still restore a different backup if you guess wrong. That’s not possible with lagged database copies.
ABOUT THE AUTHOR:
Brien Posey is a seven-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Brien worked as a CIO for a national chain of hospitals and healthcare facilities. He has also served as a network administrator for some of the nation’s largest insurance companies and for the Department of Defense at Fort Knox.