The following is tip #18 from "20 tips on protecting and recovering Exchange data in 20 minutes," excerpted from...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
the book, "Mission Critical Microsoft Exchange 2003" (Digital Press, a division of Elsevier, Copyright 2004). For more information about this book and other computing titles, please click here. Return to the main page for more tips on this topic.
In order to support the VSS framework, an application like Exchange Server must provide the VSS writer component. For previous versions of Exchange (v4.0 -- 2000), Microsoft has not and will not provide a writer and, therefore, does not support VSS for these versions.
However, the Exchange Server 2003 release does provide VSS support for Exchange information store backup and recovery. In Exchange Server 2003, Microsoft has built the VSS writer functionality into the information store (STORE.EXE) process of Exchange Server. This writer will provide the necessary support for VSS requestors to initiate backup operations for Exchange Server 2003.
Exchange Server 2003 backups using VSS
Traditional Exchange API-based backups focused on four backup types for Exchange databases: full, incremental, differential and copy.
However, the Exchange 2003 VSS writer supports only a full backup at the storage group (SG) level. VSS performs Exchange Full backups at the SG level, even though the Exchange writer treats individual databases as separate components. VSS uses the AddComponent call to add each database component to the shadow copy set, which in the case of a Full backup, is the entire SG (i.e., databases or log files).
In a Full backup of an SG, VSS creates a complete shadow copy of all volumes that contain Exchange data -- the shadow copy contains database and transaction log files associated with that SG. In addition, as is the case with non-VSS full backups, VSS truncates the transaction log files after successfully creating and backing up the shadow copy. To truncate the transaction log files, the shadow copy set must include all databases. For this reason, Microsoft will use the metadata definition for the Exchange writer to force the requestor applications to process only full backups that have all SG components (i.e., databases or log files) in the shadow copy set.
Exchange VSS full backup -- VSS backups for Exchange will be at the SG level. This is the case even though individual databases are treated as separate components. Each database VSS component is added (with the AddComponent call) to the shadow copy set (which, in the case of a full backup, is the entire storage group -- databases and log files).
In a full backup of a storage group, a complete shadow copy is created of all the volumes (containing database and transaction log files) associated with that storage group. In addition, as is the case with non-VSS full backups, the transaction log files will be truncated after successful shadow copy creation and backup. In order for the transaction log files to be truncated, all databases must be included in the shadow copy set.
For this reason, Microsoft will force (via the metadata definition for the Exchange writer) requestor applications to only process full backups that have all storage group components (databases and logs) included in the shadow copy set.
Exchange Server 2003 recovery using VSS
Although VSS backup for Exchange 2003 is at the SG level, you can recover individual databases from the SG snapshot set -- each shadow copy has the individual database files, plus the logs needed to reconstitute them.
VSS-based restoration of an Exchange 2003 SG is useful when data in one or more databases in the SG is lost or corrupted, but the current log files remain intact on disk; when the current log files on disk are lost or corrupted, but the databases remain intact; or when databases and current log files within an SG are lost or corrupted.
In the context of Exchange 2003 and VSS, only the backup application is responsible for restoring data to disk. The Exchange 2003 database engine, not the requestor, is responsible for recovering the data to a consis¬tent, up-to-date state through playback of the log file. To do so, the database engine activates existing soft or hard-recovery procedures after the VSS-aware backup application restores the transaction log files and databases. Once the restore is complete, Exchange 2003 remounts and restarts the SG, and then the database engine initiates recovery. The database engine determines that the state of the databases isn't consistent with the end of the log file on disk and begins the recovery procedure.
Three Exchange 2003 data-restoration scenarios exist, but only two procedures for those scenarios exist. The roll-forward recovery and point-in-time recovery procedures for restoring data are the same whether you have lost only the SG's log files or you have lost an SG's log files and databases. You use the same procedure because the loss of the log files is a catastrophic failure in Exchange and requires restoring the entire SG. In either case, these recovery options follow a specific step-by-step process
1. The affected storage group is taken off-line.
2. VSS-based recovery is initiated. This includes all of the volumes contained in the SG shadow copy set.
-- If one LUN is configured per SG, Exchange recovers all databases except those that are intact.
-- If multiple LUNs per SG are configured, Exchange recovers only the LUNs with the databases needing recovery from the Shadow Copy set.
3. Exchange performs an Extensible Storage Engine (ESE) hard recovery and replays applicable log files for databases being recovered, depending on whether a roll-forward recovery or point-in-time recovery is occurring.
4. The storage group is remounted and resumes normal on-line operations.
Roll-forward recovery -- In a roll-forward recovery, one or more databases in the SG are lost, but the log files are intact on the server at the time of the recovery. In this case, you can selectively restore each of the affected databases from a full backup of the SG. Within the context of the VSS framework, you select from the SG backup only those database components that correspond with the databases you want to restore. The VSS-aware backup application restores the databases, and then Exchange recovers the databases and brings them up to date from their state at the time of the snapshot by rolling forward through the transaction logs (Exchange hard recovery). The roll-forward recovery option lets you recover backed up data as well as data that has accumulated (e.g., in transaction logs) since the last backup.
Point-in-time recovery -- When the SG's log-file volume has been damaged or lost or the log files have been lost or damaged together with some or all of the SG's databases, you must restore the log files from a previous backup, together with all the databases backed up at the time of the last full backup of the SG. You cannot recover to the point of the failure because the log files and databases since the last backup have been lost or damaged, so you can recover only to the point of the last full backup. This process is known as a point-in-time recovery. Because this option does not provide roll-forward capability, some data will be lost (e.g., data between the point in time of the recovery and the time of the failure). To provide point-in-time recovery, you must restore the databases that you backed up at the time of the full backup as well as the log files from the full backup. In addition, you must recover all databases associated with the SG. You cannot assume that any of the databases were left in a transaction-consistent state at the time the log files were lost and went off-line, because the loss of the transaction log is a fatal error that causes the store to shut down immediately with no guarantee of consistency. Therefore, to ensure that the databases are in a consistent state when you restart the SG, you must return the entire SG to its state at the time of the last Full backup.
Implications for Exchange administrators
As organizations move from previous versions of Windows (NT4 and Win2K) and Exchange (Exchange 4.0 -- 2000) to Windows Server 2003 and Exchange Server 2003, the use of VSS-based backup and recovery will become a standard mechanism for Exchange disaster recovery.
However, I must concede that VSS solutions are not yet proven or readily available. The non-VSS solutions that exist today allow snapshot and clone technologies to be utilized with Exchange Server. However, these technologies have no native operating system or application support.
As a result, support from Microsoft for these solutions is limited -- see Table below for a listing of pertinent Microsoft Product Support Services (PSS) Knowledge Base (Q) articles. Organizations must therefore rely on the vendors of these solutions for support -- both for current non-VSS solutions and for future support and adoption of VSS solutions. At the time of this writing, third-party vendor support for VSS is a bit unknown (for both VSS providers and requestors) but vendors such as EMC, HP, Hitachi, Veritas, and CommVault are leading the way with VSS-enabled solutions released or in beta. Yet it will only be through extensive testing and deployment of these solutions that we will understand the power and utility they bring us. Until Exchange Server 2003 is widely deployed on Windows Server 2003 and vendors have done their part to embrace Windows VSS, the jury is still out as to whether this technology will really help us make our Exchange servers more available. However, as you may imagine, the potential here is huge.
Microsoft Knowledge Base Articles Discussion Snap/Clone Support for Previous Versions of Exchange Server
|Microsoft Knowledge Base "Q" Article||Subject|
|Q237767||XADM: Understanding Offline and Snapshot Backups|
|Q311898||XADM: Hot Split Snapshot Backups of Exchange|
|Q296787||XADM: Off-line Backup and Restore Procedures for Exchange Server 4.0, 5.0, and 5.5|
|Q296788||XADM: Off-line Backup and Restore Procedures for Exchange 2000 Server|
Get more "20 tips on protecting and recovering Exchange data in 20 minutes." Return to the main page.
About the author: Jerry Cochran is a contributing editor for Windows IT Pro and Exchange & Outlook Administrator and a group program manager for Microsoft. He is the author of Mission-Critical Microsoft Exchange 2000 (Digital Press).