How does Exchange Native Data Protection work?

The concept of Exchange Native Data Protection was born with Database Availability Groups in Exchange 2010. Simply put, Exchange Native Data Protection relies on Database Availability Group replication as an alternative to traditional backup options.

When you have three or more database copies in a Database Availability Group, you can identify additional copies as backups. This concept was initially adopted with some trepidation because traditional backups have been a fundamental part of Exchange administrators' way of life for so long. However, it has grown in use. It's even become part of Microsoft's Preferred Architecture recommendation for Exchange 2013.

The potential cost savings of not having to run traditional backups is a compelling argument for Exchange Native Data Protection. But it's important to note that if you have only a few non-lagged database copies in a database availability group (DAG), you should still use a traditional backup method. Consider Windows Backup, Data Protection Manager or a third-party Exchange Volume Shadow Copy Service-compatible backup option for data protection.

There are four important aspects to Exchange Native Data Protection. First, Exchange Native Data Protection (DAG Replication) is a continuous process and you won't need to schedule backups. Exchange 2013 Database's Transaction logs are replicated at the block level between member servers that hold a database copy in a DAG. 

Second, you identify the backup database copies by configuring Replay Lag Time settings on at least one database copy; these are generally referred to as "lagged copies." These settings allow you to delay committing the replicated changes to a specific replica copy, but this doesn't prevent replicating the transaction log data -- this only applies to writing data to the specified database. The default setting is 0, but can be configured to up to 14 days. Like traditional backups, Lagged database copies protect against the most insidious of all data loss scenarios -- database logical corruption and store logical corruption -- by giving a point in time prior to the corruption/data loss.

Third, you must configure log truncation if traditional backups aren't truncating log files. One fringe benefit of performing Exchange backups is that transaction log growth is kept under control. Native Protection doesn't do this; you must configure Truncation Lag Time settings to address the issue. The default value is 0 and can be configured up to 14 days.

The following criteria must also be met:

• The log file must be older than the checkpoint for the database.
• The log file must be older than the Replay Lag Time plus the Truncation Lag Time settings.
• The log file must already be truncated on the active copy of the database.

Alternatively, it's possible to enable Circular Logging on databases in a DAG. Circular Logging is replication-aware and won't truncate logs that don't meet stick requirements.

Fourth, recovering from a lagged copy is different than recovering from a traditional backup. It's easy to recover from a lagged copy with all of the log files and make it a current active copy. Recovering a lagged copy to a specific point in time, however, can be tricky. You'll need to manipulate log files with the low-level Eseutil tool; both processes are detailed in this TechNet article.

About the author: 
Richard Luckett is a consultant and instructor specializing in messaging and unified communications. He's been a certified professional with Microsoft since 1996 and has 20 years of experience in the public and private sectors. He's a Microsoft Certified Trainer with more than 15 years of training experience with the Microsoft product line and received the Exchange MVP award in 2006, 2007 and 2008. He's also an expert in deploying and integrating Exchange Server and Lync Server. He leads the Microsoft training and consulting practice at LITSG.