This documentation is archived and is not being maintained.

VSS Frequently Asked Questions

The following are common questions that developers often ask about using the Volume Shadow Copy Service (VSS) with Microsoft Exchange Server 2010, and the answers to those questions.

Yes, the CHKSGFILES API has been tested for use in multithreaded applications. However, there are limitations, and not all operations can be performed concurrently. For more information, see Using CHKSGFILES in a Multithreaded Application in this SDK.

The Store Writer feature in Exchange 2010 enables you to run a recovery operation at the end of a restore operation. If this option is selected, the Store Writer will replay all the transaction log files that are found in the temporary log directory (_restoredlogs). Also, if the restores are done to the original database and no temporary log folders are involved, the transaction log files in the current database log file path will be replayed. To have replay stop at a specific point in time, either the Exchange administrator or the backup application can remove unwanted log files from the log file paths before initiating recovery.

Yes. The requester must restore the files to the correct file paths and specify the location by using the SetRestoreOptions and AddNewTarget functions.

Yes and no. In Exchange 2010, storage groups no longer exist. However, the requester can specify that the restored database be mounted as a recovery database. Note that each Exchange 2010 server can have only one recovery database mounted at a time.

No. Before you can restore a database, the requesting backup and restore application must ensure that the target database is dismounted and selected for overwriting. After the restored data is in place, you can then have the backup and restore application remount the database by using Exchange management tasks or APIs.

Both the Store Writer and the Replication Writer in Exchange 2010 support full, copy, differential, and incremental backups.

This can occur when you attempt to back up a Database Availability Group (DAG) mailbox database's passive node. If the Exchange server hosting the active copy of that database is also hosting passive or replica copies of other DAG databases, the backup may fail. You can confirm this result by checking the Windows event log on the mailbox server hosting the inactive copy: search for an error with event ID 2026, error code C8000405, and MSExchangeRepl selected in the Source field. If you encounter this issue, you can work around it by ensuring that all databases are set as active on the server hosting the active copy of the database you’re attempting to back up. After you successfully back up the inactive mailbox copy, you can return the other databases to their inactive states if you want.

This error typically indicates that the specified database is dismounted. A database backup succeeds only if the database is mounted before the backup operation begins. To verify that this is the problem, examine the Windows application event log for an error with error code 9607, MSExchangeIS selected in the Source field, and Exchange Writer selected in the Category field. The event data specifies the database that was not mounted when the backup operation was attempted.

This error typically indicates that the specified database is mounted. Note that you can restore a database only if it is dismounted. To verify that this is the problem, examine the Windows application event log for an error with error number 9633, MSExchangeIS selected in the Source field, and Exchange Writer selected in the Category field. The event data specifies the database that was mounted when the restore operation was attempted.

The amount of disk space required for a shadow copy depends on how the shadow copy mechanism is implemented, including both the storage hardware and software you’re using. Some shadow copy implementations might consume the same amount of space as the original, whereas other implementations might provide efficient data compression to save space. The amount of required disk space depends on how the backup and restore application is designed and will therefore vary among applications.

Yes. Windows Server 2008 Volume Shadow Copy Service (VSS) supports a maximum of 512 hardware shadow copies per volume, using the system provider in Windows Server 2008. The maximum number of supported shadow copies you can make in Exchange 2010 depends on the VSS hardware provider. Note that the VSS framework limits the number of shadow-copied volumes in a shadow copy set to a maximum of 64.

No. Data is not flushed to the database files during a backup. For backups from the active copy (that is, using the Store Writer), all open log files are closed and written to disk, but no additional transactions are written to the database or logs. For backups from a Database Availability Group (DAG) copy location (using the Replication Writer), a temporary log file is created if one does not already exist, log copying and replay are stopped, and data is not flushed to the copy database files.

No. Exchange 2010 does not support streaming-style backups.

If you’re using the Store Writer and you try to select the lower-level components inside a database for backup, your ADDComponent calls may succeed. In that case, however, you will later receive a MAPI_E_NOT_FOUND error during the OnPrepareBackup event.

To display a list of databases in a more user-friendly format, use the Caption property and not the Name property.

Yes and no. If the database being backed up is a member of a Database Availability Group (DAG) and there are at least two viable copies of the database, the risk of not performing a database consistency check is minimal. The internal verification processes in Exchange 2010 greatly reduce the likelihood of database corruption in DAG configurations. So if your backup and restore application is backing up a database that has at least two good copies, the application doesn’t need to perform a database consistency check on the backed-up data before calling the BackupComplete function. However, the application still must verify the checksum values for the log files that are being backed up. If your application is backing up a stand-alone database, which by definition has only one copy, the application must verify the consistency of both the database files and the log files before calling BackupComplete.

Event logging is the only extra tracing mechanism that can be turned on in Exchange 2010. To modify the level of event logging for the Store Writer, perform the steps in the following procedure:

  1. Open Microsoft Exchange System Manager.

  2. Find the Server object.

  3. Right-click the name of the server for which you want to change the logging level, and then click Properties.

  4. Click the Diagnostics Logging tab.

  5. Expand the MSExchangeIS node in the Services pane, and then click System.

  6. Click Exchange writer in the Categories pane, and then select the logging level you want.

  7. Click Apply, and then click OK to close the Properties dialog box.

Note that all event logging for the Replication Writer is done at the server's default logging level.

Yes. The VSS framework does enable 32-bit requesters working with 64-bit writers. Keep in mind, however, that there is no 32-bit version of the Exchange 2010 consistency check library (CHKSGFILES). Also, note that using the 32-bit Exchange 2007 CHKSGFILES library with an Exchange 2010 database is not supported in Exchange 2010.

No. Exchange 2010 does not need to be installed on the proxy server. Be aware, however, that you must have Exchange 2010 administrative tools installed on the backup server before you can run the consistency checks.

Yes. Bear in mind, though, that only 64-bit versions of admin-only installation tools are available for Exchange 2010. These tools install the Exchange Management Shell binary files for management tasks, as well as the CHKSGFILES.DLL file for running database consistency checks.

Yes. You can use the 64-bit version of Exchange 2010 to run consistency checks against Exchange 2003 and 2007 database and transaction log files. Exceptions to this are the CHKSGFILES APIs, which do not support running consistency checks against Exchange 2003 STM files because that requires the databases to be in a clean-shutdown state.

Not exactly. The LCR and CCR features are not part of Exchange 2010; rather, they are now part of the Database Mobility features.

Yes, but with limitations. You can use backup data created by using the Exchange writers to reseed a DAG copy if that same backup data is used to reseed all copies of the database. Restoring some but not all of the active and passive database copies is not supported in Exchange 2010. Before you can restore a passive copy, you must first have the restore application place the restored database files in the database directory. Using the Store Writer to place the files in this scenario is not supported in Exchange 2010 and should not be attempted. For more information, see Restoring a Database Availability Group Copy in this SDK.

The requirement to checksum the backup prior to calling Backup Complete (to truncate logs) is different in Exchange 2010 based on new data protection features such as Mailbox Resiliency (Database Availability Groups) and Background Database Maintenance (24x7 Checksumming). The following table lists the requirements for mailbox resiliency protected and non-mailbox resiliency protected databases.

Mailbox resiliency protected databases

Standalone/Non-mailbox resiliency protected databases

  • Database .edb files do not need to have checksgfiles/checksummed run against them prior to calling Backup Complete. Exchange 2010 has a mechanism to continually checksum the database files (Background Database Maintenance).

  • It is recommended that the Database .edb backups be checksummed, but it is okay to do this after Backup Complete is called. For a very tight VSS backup schedule, not all backups would need to be checksummed (at least once per day).

  • Database log files do need to have checksgfiles/checksummed run against them prior to calling Backup Complete. Exchange 2010 does not have a mechanism to continuously checksum the log files (they are only checksummed when replicated and when inspected.

  • Database .edb files do need to have checksgfiles/checksummed run against them prior to calling Backup Complete. This is the same policy that is outlined for previous versions of Exchange (http://support.microsoft.com/kb/822896)

  • Database log files do need to have checksgfiles/checksummed run against them prior to calling Backup Complete. Exchange 2010 does not have a mechanism to continuously checksum the log files (they are only checksummed when replicated and when inspected.

:

Show: