Lagged Copy Database: A Story of the Tortoise and the Hare

The fable of the tortoise and the hare is one of the oldest stories around. We’ve all heard it before. The speedy hare, all flash and dash, looks the greatest on the way to the finish line. The tortoise is hardy and durable—when the speedster runs out of gas, this little guy just keeps plodding away, and he can be counted on to always make it to the finish line. When it comes to Exchange Server mailbox databases, you want to have a little bit of both to get the most out of your system.

I’m talking, of course, about Database Availability Group (or DAG): additional database copies and their logfile playback. Before any transaction is written into the database, it is first written to a logfile. Only then is the transaction patched into the database.

The Hare

In a DAG, those logfiles are first written locally.  They are then shipped to the other members of the DAG that host copies of that same database. By default, the logfiles are written into the passive databases right away. They act as the high availability copies of each database and protect you when the mounted copy of a database becomes unavailable. In that instance, Active Manager finds the next best available copy of the database and immediately directs users to it.  Speedy – like the hare.

The Tortoise

However, there are good reasons to designate one of your copies as a lagged database copy. In a lagged configuration, the server hosting this copy waits a specified period before it writes the logs into the database. This period is configurable; should you choose to enable it, be sure to align the delay with your defined Service Level Agreements (SLAs).  Microsoft’s guidance is 7 days.  Slow and steady – like the tortoise.

A Caveat

Microsoft has some recommendations before designating one of your database copies as a lagged copy. Microsoft’s Preferred Architecture, which was built from their experience managing Exchange Online, recommends a minimum of three HA (high availability, aka non-lagged) copies of a mailbox database. Only then can you designate a fourth copy as a lagged copy.

Why would you use a Lagged Copy Database?

  • It allows you to recover from logical corruption (either database logical corruption, or store logical corruption) in your database.
  • You can copy the files to another drive and restore the database to a point in time; useful as a recovery database.
  • Finally, lagged copies are essential if you’re considering Exchange Server Native Data Protection

Deploying four database copies (three HA copies and one lagged copy), along with Single Item Recovery, In-Place Hold, and Deleted Item Retention, can enable your organization to stop using traditional backups.

Configuring these features to meet or exceed your SLAs will help you fulfill requests from users to restore deleted emails. With a correctly configured Deleted Item Retention value, your users can restore their own emails without a call to the Support Desk! (And starting with Exchange Server 2016 CU6, the restored emails are restored to their original folder, rather than the Deleted Items folder!!) Want to learn more?  Contact us at info@peters.com.  We are happy to help!

By | 2018-02-07T12:40:51+00:00 February 5th, 2018|IT Advisory Services|0 Comments

About the Author:

Leave A Comment