1578 - Understanding VSS and log truncation behaviour

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.
• 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.

Read more in Article 531 - How Redstor's software uses VSS.