AppAssure performs Exchange log truncation by calling a full VSS shadow copy backup. This process calls all VSS writers including the Exchange Writers. Exchange Writers coordinate with the Exchange services (operating on behalf of the requestor) to prepare the database files for backups, freeze the IO activity resulting from Exchange transactions before backing up the database, and then to unfreeze and truncate log files after the backup is complete to quiesce the application data to disk (http://msdn.microsoft.com/en-us/library/bb204080(v=exchg.140).aspx). If AppAssure is able to successfully call a full shadow copy backup and complete the backup of data to AppAssure successfully, then AppAssure will consider log truncation performed and will update the Exchange log truncation counters in the core web UI. This update will happen regardless of whether any logs were truncated or not.
If logs are not truncating properly then the entire process, from AppAssure calling a snapshot to logs being truncated, must be reviewed to make sure there are no errors.
If Exchange logs are not truncating please follow these steps:
If there are no errors, then please review the following information regarding log truncation as it may not be necessary for Exchange to truncate logs at the time the job was run. According to Microsoft (http://technet.microsoft.com/en-us/library/dd335158(v=exchg.150).aspx_): Log truncation works the same in Exchange 2013 as it did in Exchange 2010. Truncation behavior is determined by the replay lag time and truncation lag time settings for the copy.
The following criteria must be met for a database copy’s log file to be truncated when lag settings are left at their default values of 0 (disabled):
The following criteria must be met for truncation to occur for a lagged database copy:
To find the checkpoint time for a database please follow the steps in this article -http://blogs.technet.com/b/timmcmic/archive/2012/03/12/exchange-2010-log-truncation-and-checkpoint-at-log-creation-in-a-database-availability-group.aspx
Hence if there are no logs that meet the above criteria, then log truncation will not be performed. To verify that Exchange log truncation has been called and attempted to run, review the Application Log for ESE Event ID 224 and 225. Event 224 indicates that logs are being deleted and denotes the associated database. Event 225 indicates that there were no logs available for truncation.
It's also possible to verify Exchange 2010 logs truncation functionality outside of AppAssure/Rapid Recovery using the following VSStester script: https://blogs.technet.microsoft.com/exchange/2013/04/29/troubleshoot-your-exchange-2010-database-backup-functionality-with-vsstester-script/
© ALL RIGHTS RESERVED. Feedback Terms of Use Privacy Cookie Preference Center