Log file truncation, or deleting the transactional log files that are no longer required for a successful database restore, takes place once you do a successful backup. But if you do not perform a backup in situations where you decided to no longer use traditional point-in-time backups, how will you make sure the log files are removed so they don’t pile up? Simple: they are never removed.

Once you enable circular logging when multiple database copies are in place, you get a new type of circular logging called continuous replication circular logging (CRCL) which behaves differently from traditional circular logging known from Exchange 2007 and before.

CRCL is performed by the Microsoft Exchange Replication Service, not the Microsoft Exchange Information Store service. Also, CRCL requires considering log files that are required for log shipping and replay before removing them. This situation needs special logic to ensure that all database copies process the log file before it is removed, which differs from the traditional circular logging logic where the log file was deleted when it was committed to the database.

When CRCL is enabled, log file truncation for database copies that are not lagged occurs in the following way:

• The log file is checked to determine whether it is below the checkpoint.
• The log file is inspected that all other non-lagged database copies replayed the log file into their database.
• The log file has been inspected by all database copies (including any lagged database
  copies).

Log file truncation happens for lagged database copies in the following way:

• The log file is checked to determine whether it is below the checkpoint.
• The log file is older than ReplayLagTime and TruncationLagTime.
• The log file is already deleted on an active database copy and all copies agree on the
  deletion.