Inside a lab, an Exchange 2013 DAG with 2 mailbox servers exists. Each mailbox server is placed in its own Active Directory site. There's only one forest/one domain - fabrikam.com. A DC is placed in each of the AD sites. A mailbox database is created on one of the mailbox servers, and a copy is added and seeded on the other node. No copy or replay queues exist, and both copies are healthy (including the content index).

Using the built-in Windows Server backup application, a full VSS backup is ran and completes successfully against the passive copy. The following message is emitted in the Application Log: "Database log truncation has been requested for this database. Log truncation will occur on the active copy after the next log generation is created. Log truncation will occur automatically on the passive copies after that log file is copied." However only the logs before the previous successful backup that ran are truncated. According to a blog post for Exchange Server 2010 here, it's quite normal to still have multiple log files remaining after a successful backup against a database with at least one passive copy due to a concept known as checkpoint depth. The same behavior is still present in Exchange Server 2013, based on the latest comments on the article.

Still, analyzing further presents a couple of issues.

The process described in the article is as follows: 1. all passive DB copies report to the active one the maximum log file that they determine can be truncated; 2. the active copy does a min() against all the reported numbers; 3. the active copy analyzes this log file in its own log stream and checks the "Checkpoint at log creation" value; 4. the active copy will truncate all the logs below the value determined at 3; 5. DB copies will replicate the deletion.

I'm not sure how to get the reported values in 1. above (doesn't look to be written to the event viewer), however analyzing the logs generated just before the backup was taken on both DB copies yields a "checkpoint at log creation" value that's only 1 or 2 lower that the log file itself (screen below). However I'm left with about 10 log files - so it's either one of the DB copies that believes it cannot truncate below one of the older log files or something else I can't just figure out.