A common task during Exchange-aware backups is the truncation of transaction log files after the backup has completed successfully. One nuance of taking a backup of a passive storage group is that Exchange-aware backups modify the header of the database. For example, the backup process adds information about the time of the last backup of the database. VSS backups are made possible by the Exchange Replica VSS Writer that is built into the Microsoft Exchange Replication service. Although the Microsoft Exchange Replication service can replay log files into its copy of each database, it cannot independently modify its copy of the database because that would produce divergence. Therefore, it cannot modify the header of its database copy.

As a result, in Exchange 2007, the Microsoft Exchange Replication service coordinates its backups with the Microsoft Exchange Information Store service. As soon as you start a backup of a passive storage group, the Microsoft Exchange Replication service contacts the Microsoft Exchange Information Store service that controls the active group and tells it that a backup is about to start. This is done to prevent the same storage group on both the active and the passive nodes from being backed up simultaneously. After the backup is finished, the Microsoft Exchange Replication service contacts the Microsoft Exchange Information Store service and lets it know that the backup completed.

The database header modifications resulting from the backup are then made by the Microsoft Exchange Information Store service on the active storage group. This action generates a log record, which through continuous replication is copied to the passive node. When it is replayed, the database header on the passive node is then updated. This approach is more complex than traditional backups, and it has some interesting side effects. For example, if you back up a passive storage group and then immediately after the backup has finished, you look at the database header on the passive node, it will not reflect the backup. The database header on the active side will however reflect it. Thus, if you are backing up databases in a continuous replication environment, looking at the database on the active node is the most accurate way to determine the time of the last backup. Another side effect is that, if the Microsoft Exchange Information Store service is not running, you cannot make backups from the passive node. Running the Microsoft Exchange Information Store service is required so that backups can be coordinated and the database header can be updated.

With log files being copied and required by the Microsoft Exchange Replication service, it becomes more complicated when removing them. Currently, the conventional way to remove log files is to run a backup. Backup runs, and when it completes successfully, it deletes the logs you no longer need. The introduction of continuous replication changes the definition of need because now it takes into account the state of replication. If a log file has not been copied, it is still needed (even though the Microsoft Exchange Information Store service might not need it). As a result, a log file is not deleted until:

• It is not needed for failure recovery.
  
  
• It has been replayed on the passive node.
  
  
• It has been backed up.
  
  

To coordinate this, whenever the Microsoft Exchange Replication service finishes a replay, it contacts the Microsoft Exchange Information Store service and says that it replayed storage group X up to Y generation number. At that point, the Microsoft Exchange Information Store service knows that log files up to that generation number are no longer needed by the Microsoft Exchange Replication service. It can then analyze the state of the last backup and failure recovery, and it can work out which log files are no longer needed on the active node. On the passive node, things are even simpler. The passive node can analyze its own log files and determine which ones are needed for recovery, and which ones are needed for backup.