The concept of lagged database copies was introduced in Exchange 2007, implemented using Standby Continuous Replication (SCR). With SCR, we can delay the time when the logs have to be replayed to the SCR target. There is also the option of specifying truncation lag time, the option which allows us to delay the time before the log files are truncated. The maximum lag time for both the options is 7 days in Exchange 2007.
With Exchange 2010 DAG, the lag time for both replaying and deleting the logs have been increased to 14 days. This is good if your company wants to go backup-less. Of course, the company has to be aware of the risk of going without backups, as lagged database copies can’t be a solution for all recovery/restore issues.
The two parameters you need to know are ReplayLagTime and TruncationLagTime. The ReplayLagtime parameter specifies the amount of time that the Exchange Replication Service should wait before replaying log files that have been copied to the database copy location. The format for this parameter is Days.Hours:Minutes:Seconds. The default value is zero seconds.
The TruncationLagTime parameter specifies the amount of time that Exchange Replication Service should wait before truncating the log files that have replayed into a database copy. The time period begins after the log has been successfully replayed into the database copy. The format for this parameter is Days.Hours:Minutes:Seconds.
The lag times can be configured either while setting up the database copy (Add-MailboxDatabaseCopy) or after setting up (Set-MailboxDatabaseCopy).
Leave a Reply