Introduction to VSS Backup and Restore
You can use the Volume Shadow Copy Service in Windows Server 2008 to create applications that back up and restore Microsoft Exchange Server 2010 data. The Volume Shadow Copy Service (VSS) provides an infrastructure that enables third-party storage management programs, business programs, and hardware providers to cooperate to create and manage shadow copies. Solutions that are based on this infrastructure, and use the Exchange 2010 VSS Writer, can use the shadow copies to back up and restore one or more Exchange 2010 databases.
Components of an Exchange 2010 Backup and Restore Application
VSS coordinates communication between VSS requestors (for example, backup applications), VSS writers (for example, the Exchange 2010 VSS Writer), and VSS providers (system, software, or hardware components that create the shadow copies).
To use VSS to back up Exchange 2010 data, the backup application must be an Exchange 2010–aware VSS requestor. Exchange 2010 includes VSS writer for the Windows Server 2008 backup program that is Exchange-aware. However, that VSS writer only backs up whole volumes. It cannot be used to backup individual Exchange 2010 databases. To achieve greater backup flexibility, organizations can use third-party backup applications having an Exchange-aware requestor that can work with individual Exchange databases, or create a custom requestor.
Before calling VSS to initiate a backup, the application must obtain information about the storage configuration for the Exchange 2010 system that it is backing up. In Exchange 2010, that information is stored in Active Directory Domain Services (AD DS). The backup application can more easily get Exchange storage configuration data by using the Exchange-specific Windows PowerShell commands.
The backup application does not directly interact with the Exchange 2010 VSS Writer. Instead, the application calls the VSS COM APIs. Exchange 2010 backup applications can use VSS to create Full, Copy, Differential and Incremental backups of Exchange databases.
The new Database Available Group (DAG) functionality in Exchange also enables your application to create a fully consistent backup even though the base full backup and later incremental backups come from different servers in the DAG.
After VSS creates the copy of the Exchange data, it’s up to the backup application to store the data onto the intended media. This SDK doesn’t cover that because getting data to and from media is usually the backup application developer’s specialty.
To restore an Exchange 2010 database, the restore application retrieves the database and log files from the backup media, and places them onto the active disk storage of an Exchange server. Unlike in earlier versions of Exchange, individual databases are not tied to a particular Exchange server, and Exchange storage groups are not part of Exchange 2010.
Reconstructing a database that had changes since the last full back requires database and log files from different backups. For example, a weekly full backup and one or more daily incremental backups might be required. In Exchange 2010 systems that use DAGs, the restore application can rebuild a database by using backups from different database copies on different servers in the same DAG. However, the only supported situation for restoring a DAG database from backup is when all active and passive copies of the database are restored using the same data. For more information about how Exchange 2010 Database Mobility and DAGs can be used in your backup and restore applications, see Changes to Backup and Restore in Exchange 2010.
After all the data is in place, the restore application tells Exchange to check the integrity of the database and log files. If the database and log files have been restored correctly, the Exchange server can then replay the database log files to bring it up to date, and finally mount it. If the database has been recovered to a server that already has an active copy of the database mounted, the database is treated as a Recover Database. If the database has been recovered onto a different server entirely, the database either can be independently mounted, or that replica can then be added into the DAG.
Using This SDK to Create Backup and Restore Applications
Because all the content in the Exchange 2010 Backup and Restore SDK is focused on creating VSS-based backup and restore applications for Exchange 2010, we recommend that you carefully read the topics in this SDK to help you to create your applications.
If you are creating applications that use VSS to back up Exchange for the first time, you should also read the VSS SDK.
Full-featured backup and restore applications that work with Exchange 2010 have unusually diverse system requirements. For example, the CHKSGFILES DLL API can be accessed only from native 64-bit code. The VSS APIs are COM-based native-code APIs, and PowerShell is a Microsoft .NET managed application. Be sure to read the System Requirements topic so your application can properly access these different components.
Although the PowerShell SDK is primarily focused on creating commands that work with PowerShell, you can find good information there about calling PowerShell commands from your applications. After you become familiar with PowerShell commands, scripting, and programming, read the Determining Exchange Server 2010 Storage Configuration topic.
For details about the new backup and restore capabilities in Exchange 2010, be sure to read Changes to Backup and Restore in Exchange 2010.
Exchange 2010 includes enhancements to the database store that improve the reliability and consistency of the database, and therefore reduce the need to perform a full consistency check after taking the VSS snapshot. For cases where your backup application needs to check the consistency of a database, however, the CHKSGFILES API is still available.