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 b...
Published Aug 18, 2010
Version 1.0
Blog Post
Sukum,
That is a good question. It all comes down to how the Exchange VSS Writer handles the backup scenario. Here is some documentation: http://msdn.microsoft.com/en-us/library/bb204080(EXCHG.140).aspx
Remember that Exchange is a transactional database. What this means is that any time a change is made to an Exchange database, it must be written to the transaction log files. Until it is written, it didn't happen. These transactions are stored in memory in the database cache as "dirty pages" (meaning that they are updated since they were last read from disk). Which pages are "dirty" is tracked in the Version Store (you might have heard of "version buckets", which is a grouping in the version store). Then, some time later, a process called "the lazy writer" comes along and writes these changed pages from the database cache to the database. (NOTE: This is a fairly simplified version of the process!)
There is a special file called the checkpoint file that points to the oldest transaction log file that has any data in it that has not been written to the database. This is used by Exchange to recover a database after a crash - the database knows that it can just "play forward" the transactions in the log files after the checkpoint and build a database that has all of the updates and changes made before it crashed and lost the dirty pages in the cache. (Once again, oversimplication is possible...)
Now, when you do a backup of the database (a full backup), VSS will either get a full backup of the database, or a block-wise partial backup that can be combined with an older full backup to create what the database looks like at the time of the backup (DPM would call this an express full). After that completes, the VSS writer tells Exchange "I backed up the database, you can truncate up to the checkpoint file."
As for incrementals, at least the way DPM does them (I am not familiar with other backup software), the VSS backup will copy the transaction log files that have been generated since the last truncation. Then, the VSS writer informs Exchange that it can truncate because a successful incremental backup occurred, and Exchange truncates up to the checkpoint.
Exchange keeps track of the backups that have occurred, as does the backup software. It is the responsibility of the backup software to inform Exchange that the backup was successful, that the data was validated (assuming they validate the backup data), and that the log files can be truncated to a certain point.
Does this help?
That is a good question. It all comes down to how the Exchange VSS Writer handles the backup scenario. Here is some documentation: http://msdn.microsoft.com/en-us/library/bb204080(EXCHG.140).aspx
Remember that Exchange is a transactional database. What this means is that any time a change is made to an Exchange database, it must be written to the transaction log files. Until it is written, it didn't happen. These transactions are stored in memory in the database cache as "dirty pages" (meaning that they are updated since they were last read from disk). Which pages are "dirty" is tracked in the Version Store (you might have heard of "version buckets", which is a grouping in the version store). Then, some time later, a process called "the lazy writer" comes along and writes these changed pages from the database cache to the database. (NOTE: This is a fairly simplified version of the process!)
There is a special file called the checkpoint file that points to the oldest transaction log file that has any data in it that has not been written to the database. This is used by Exchange to recover a database after a crash - the database knows that it can just "play forward" the transactions in the log files after the checkpoint and build a database that has all of the updates and changes made before it crashed and lost the dirty pages in the cache. (Once again, oversimplication is possible...)
Now, when you do a backup of the database (a full backup), VSS will either get a full backup of the database, or a block-wise partial backup that can be combined with an older full backup to create what the database looks like at the time of the backup (DPM would call this an express full). After that completes, the VSS writer tells Exchange "I backed up the database, you can truncate up to the checkpoint file."
As for incrementals, at least the way DPM does them (I am not familiar with other backup software), the VSS backup will copy the transaction log files that have been generated since the last truncation. Then, the VSS writer informs Exchange that it can truncate because a successful incremental backup occurred, and Exchange truncates up to the checkpoint.
Exchange keeps track of the backups that have occurred, as does the backup software. It is the responsibility of the backup software to inform Exchange that the backup was successful, that the data was validated (assuming they validate the backup data), and that the log files can be truncated to a certain point.
Does this help?