With Exchange 2007 a new concept was introduced, that of lagged replication (or database copies if you want). This means that besides “immediate” replication (Cluster Continuous Replication or CCR) you could delay replaying logs on target databases (Standby Continuous Replication or SCR). This enabled creating solutions for resilience since targets could be several hours off. Also, and contrary to CCR that have a 1:1 relationship, SCR targets could have 1:N or N:1 relationships (one to many, many to one).
In addition to the replay lag time in Exchange 2007, you can also specify the truncation lag time which determines when log files will be truncated. This period starts after replaying the log files. Both parameters are limited to 7 days in Exchange 2007; the default values for SCR’s ReplayLagTime is 1 day and TruncationLagTime is 0.
With Exchange 2010 DAG, which is the successor to CCR/SCR, the maximum for ReplayLagTime and TruncationLagTime have been increased to 14 days. The default value for ReplayLagTime is 0, which mimics the behaviour of CCR.
Needless to say that you should have sufficient space to host the replication log files when you set it to to a value greater than 0, also depending on the transations within that time frame. In Exchange 2010 these lag times can be configured using the cmdlets Add-MailboxDatabaseCopy or Set-MailboxDatabaseCopy, e.g. to set the ReplayLagTime to 7 days for (format Days.Hours:Minutes:Seconds) use:
Set-MailboxDatabaseCopy -identity DAG2\MBX1 -ReplayLagTime 7.0:0:0
Note that in Exchange 2010 these values can be configured on-the-fly; in Exchange 2007 you need to disable and re-enable SCR.