Our Exchange plugin backs up Exchange mailbox databases using Microsoft's best practices. The backup software uses Microsoft's Exchange VSS Writer to take a shadow copy of the information store which is what the backups will work off of rather than "live" data. The shadow copy freezes the information store at a specific point in time, which avoids the problem of having to handle files which are constantly changing (transaction logs, for example).
When the shadow copy is complete, Eseutil runs a checksum on the shadow copy to guarantee its integrity. If you are performing an incremental backup the checksum is run on the transaction logs while, for a full backup, the checksum is run on both the transaction logs and the mailbox database. When the checksums have been verified the actual backup can begin.
The backup software will then go about determining what needs to be backed up. Transaction logs are backed up as is but the mailbox database (if you are running a full backup) is scanned for changed blocks to avoid uploading the entire database. Changed blocks found by the software are complied into a single differential file in temporary space. When this changed block calculation process is complete, the differential file is chunked and uploaded to the backup destination.
Exchange Information Store backups will truncate the transaction logs for the information store you are backing up. This occurs whether you perform a full or an incremental backup. Log truncation is done by Exchange, not the backup software, and is triggered by the shadow copy action. In accordance with Microsoft's documentation, transaction log truncation occurs after the shadow copy of the information store completes. Since shadow copies are made in both full and incremental backups, log truncation occurs in both. You can verify log truncation has happened if you see events such as these: