1578 - Understanding VSS and log truncation behaviour – Redstor

Microsoft's Volume Shadow Copy Service (VSS) works by allowing the backup of open files using a "copy-on-write" journal approach, where file blocks are copied where they would be overwritten, in order to allow the file to be read as it was at the point when that snapshot began.

VSS log truncation, for some applications (including MS SQL and MS Exchange), can be a bit harder to understand, creating confusion about the expected behaviour.

At a high level, the VSS process is as follows:

A snapshot is started using the VSS writer - this is the VSS freeze.
The data is read from the source files (for data that has not changed) and from shadow copy blocks (for data that has changed).
The VSS snapshot then "thaws" and completes, and the machine returns to normal operation.

For some application-specific (i.e. not just open-file) VSS writers, a successful completion of a backup process and VSS thaw will automatically trigger log truncation on the part of the application. This is built-in functionality in Exchange/SQL VSS writers, and so may not be apparent as application functionality.

Please note that:

VSS backups in "Full" mode will truncate logs on successful completion, while "Copy" mode will not.
It should not be necessary to explicitly configure Exchange or SQL log truncation in the application.
Some application settings and fault conditions will prevent log truncation from occurring, e.g. incomplete DAG replication, as described in Article 979 - SE: Backing up and restoring Exchange 2013 DAGs.
SQL databases will only generate transaction logs if set to "Full" mode, which can be of use for point-in-time recovery. If point-in-time recovery is not required and a daily backup is sufficient, it is better to change the SQL database mode to "Simple". It should not be necessary to explicitly truncate SQL logs if you have sufficient space for the volume of transactions that are run against the database.

Related articles