In my recent post I examined the question of whether Exchange Server 2010’s new replication and retention features could mean an organization no longer needed to back up their Exchange servers.

One reader emailed me to suggest that avoiding backups would be unwise, citing the example of potential corruption within the database that might replicate to all copies within the Database Availability Group and cause loss of data.

The scenario is one that definitely needs to be considered.  Although Exchange Server 2010 includes application intelligence to detect and handle some database corruption scenarios, there still exists the possibility of logical corruption leading to data loss.

Fortunately the solution to this problem is already included in the DAG feature of Exchange Server 2010.

If you are already familiar with Exchange Server 2007 Standby Continuous Replication then you already understand the concept of replay lag time.  Replay lag time is a configurable setting on each database copy within a DAG that delays the replay of a transaction log into that database replica.  A database copy with a replay lag time of more than zero is referred to as a lagged copy.

For example, within a DAG there may be 3 servers hosting replicas of Database 1.  Two of the servers are located in a primary data center, and the third server is located at a secondary data center.

The servers at the primary data center are configured with a replay lag time of zero, meaning the passive copy of the database is kept up to date with the latest transaction log information in near real-time.  A failure of one server permits seamless failover to the second server and continued email operation for the business.

The server at the secondary data center can be configured with a lag of 24 hours.  This means that even though transaction logs are immediately replicated to the server, they are not replayed into the database copy until 24 hours later.

This configuration means some additional configurations for the high availability design of the Exchange Server 2010 environment.

• The lagged copy is not for high availability through automatic failover, rather it is for disaster recovery scenarios.
• When a lagged copy is activated it can take some time to come online depending on the number of transaction logs that need to be replayed and the speed of the server.
• When a lagged copy is activated the administrator can choose to replay all log files, or only those log files up to a certain point in time.
• Because a lagged copy is generally activated only in a disaster scenario, it is possible that no other database copies within the DAG will be functional at that point in time.  To maintain a resilient Exchange Server environment either the server hosting the lagged copies should be configured with RAID storage, or more than one server should be configured with a lagged copy of the database.
• Lagged copies are themselves susceptible to corruption.  The servers must be monitored for event log errors that indicate a problem.  When a problem occurs the lagged copy must be reseeded, which therefore temporarily loses its lagged status.