In discussions with some of our friends over in the DPM team (System Center Data Protection Manager), we’ve found that there is a rather high incidence of VSS errors in installations where DPM is being used to back up Exchange 2010. Turns out that in many instances, this is because of an incorrect configuration of circular logging on the mailbox databases being backed up, so we thought we would quickly discuss circular logging, what it is, and how it affects VSS backup scenarios.
Circular logging has been around for a long time in the Exchange world. I found KB147524, which references Exchange 4.0, and discusses circular logging. When you configure an Exchange database with circular logging turned on, Exchange doesn’t wait until a backup occurs to truncate transaction log files. Rather, as soon as the log files have been played forward into the database, Exchange is free to delete those transaction logs. In Exchange 2003 and before, this was always handled by the Information Store service.
With Exchange 2007 and later there is actually another form of circular logging, known as continuous replication circular logging (CRCL). There is a great discussion of this in the Continuous Replication Deep Dive white paper, so I’m not going to delve into the mechanics of how it works, other than to state that the system ensures that logs are not truncated on the source until all copies agree with the deletion.
Circular Logging is useful in a few scenarios:
Customers occasionally leverage circular logging on mailbox databases when performing mass mailbox moves to a single mailbox database target within a small period of time to minimize the capacity impacts that could cause an outage event on the target database. If you are deploying an Exchange solution that will continue to leverage a VSS backup infrastructure and enable circular logging it is imperative that you remember to disable circular logging prior to your next backup window, otherwise your next full or incremental backup will fail. For example, some VSS solutions perform incremental backups of Exchange data by capturing the transaction log files generated since the previous backup that managed/truncated the transaction logs (a full backup, or the previous incremental backup). If you have circular logging turned on, when the incremental backup is performed, the log files that are expected to be there since the previous backup are not there – they have been truncated – causing the backup to fail.
So, what are we saying here? We know that there are some valid and supported scenarios where circular logging is very useful. The idea here we want to reinforce is that when you are performing VSS backups that rely on the transaction logs, make sure that your normal run state is with circular logging turned off. If you have a reason to turn circular logging on when utilizing VSS incremental backups that rely on the transaction log files, remember to turn it back off as soon as reasonable, and understand that while circular logging is on that your incremental backups will fail to complete as expected!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.