Validating Backup Integrity By Using CHKSGFILES
The backup/restore application may choose to validate the integrity of a shadow copy backup set. During a backup operation managed by the Volume Shadow Copy Service, there is no opportunity for Microsoft Exchange Server 2010 to read each database file in its entirety and verify its checksum integrity. Therefore, database and transaction log file integrity should be verified by the backup application. Microsoft recommends that the backup application verify the physical consistency of the shadow copy set prior to informing the Exchange Writer that the backup is complete. Upon successful backup, Exchange store updates the headers of the backed-up databases to reflect the last successful backup times and removes transaction logs from the server that are no longer required to roll forward from the last successful backup.
Previous versions of Exchange provide no programmatic means of verifying the physical consistency of shadow copy backups. With Exchange 2003, the only solution available to backup vendors is the command-line tool Eseutil, which requires its text output to be captured and parsed and has a very basic throttling functionality.
In order to provide better granularity and control during the consistency check process, Exchange 2010 includes a set of unmanaged public APIs packaged into a DLL (chksgfiles.dll). The CHKSGFILES DLL is installed with all Exchange server roles as well as part of the Admin-only option to enable running consistency checks off of an Exchange server on a proxy backup machine.
The downloadable Exchange 2010 SDK includes the necessary header (hxx) and LIB files.
Computers that are running Exchange 2010 are exclusively 64-bit, and a 32-bit version of CHKSGFILES is not available. Exchange 2010 consistency check APIs can also be used to verify the physical consistency of Exchange 2003 and Exchange 2007 database and log files, with the following caveats:
APIs will check only the .edb and .log files, they will not check any .stm files, because verifying the physical consistency of .stm files requires the databases to be in a clean-shutdown state.
Exchange 2003, Exchange 2007, and Exchange 2010 databases cannot be checked within the same process, because the database engine only supports one page size per process. Page size for Exchange 2007 is 8K, while the page size for Exchange 2003 is 4K, and page size for Exchange 2010 is 32K.