Should we implement the lagged copies for our Exchange environment (mainly for backup-less solution). The choice will be dictated by personal preference, previous deployment history, our knowledge or support service level, but let’s see few things:
- Lagged copies are recommended (also using multiple lagged copies or redundant array) by Microsoft or Symantec (they maybe know why). It can provide protection against a range of failures that would ordinarily cause data loss. There is no way how to achieve the same protection without backup. It is best practice to have at least enough room for three additional days of transaction logs, to provide for potential truncation failures or periods of excessive log file generation.
- Lagged copies are designed for disaster recovery purposes, to protect against store logical corruption (which although rare):
- Database logical corruption (the data is either never written to the disk or it’s written to the wrong place)
- Store logical corruption (the data is added, deleted, or manipulated in a way that the user doesn’t expect. These cases are generally caused by third-party applications.)
- Rogue Admin Protection (the data is added, changed, or removed from the system in undesirable way)
Notes: If we want to replay log files up to a specific point in time, it’s a more difficult operation because we manually manipulate log files and run the Eseutil tool. The lagged copy is blank database voting member node in DAG (violates the “rule of three”).
- If we use multiple database copies and Single Item Recovery, only the extremely rare catastrophic store logical corruption case is interesting. In the following scenarios lagged database copies can be used to recover data:
- Recovering a log file that was deleted on the source
- Rolling back to a point in time because of a virus outbreak
- Recovering a deleted item that is outside the retention time (mount a lagged database as a recovery database)
- We can use two parameters: ReplayLagTime (a delay log replay for the database copy) and TruncationLagTime (a delay log deletion for the database copy after the log file has been replayed into the database copy). The replay lag time setting has a default setting of 0 days, and a maximum setting of 14 days. The greater the replay lag time, the longer the database recovery process. Depending on the number of log files that need to replayed during recovery, and the speed at which your hardware can replay them, it may take several hours or more to recover a database. At a minimum, we should see a log replay rate of two logs per second per database.
- Definitely, when planning for lagged database copies, we should carefully consider the implications this brings to your storage planning. Every lagged database needs sufficient disk space for holding the database as well as the log files for the configured time.