Exchange 2007 Data Backup and Volume Shadow Copy Services
Microsoft Exchange Server 2007 will reach end of support on April 11, 2017. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.
Applies to: Exchange Server 2007, Exchange Server 2007 SP1, Exchange Server 2007 SP2, Exchange Server 2007 SP3
The Volume Shadow Copy Service (VSS) in Windows Server 2008 is used by applications to back up and restore Microsoft Exchange Server 2007. VSS provides an infrastructure that enables third-party storage management programs, business programs, and hardware providers to cooperate in creating and managing shadow copies. Solutions based on this infrastructure can use shadow, or mirrored, copies to back up and restore one or more Exchange 2007 databases.
VSS coordinates communication between Requestors (backup applications), Writers (applications in Windows such as Exchange 2007), and Providers (system components, software components, or hardware components that create the shadow copies). To use VSS to back up Exchange 2007, a backup program must include an Exchange 2007-aware VSS Requestor. The Windows Server Backup program that is part of Windows Server 2008 does not include an Exchange-aware VSS Requestor.
However, Exchange 2007 Service Pack 3 (SP3) includes a new plug-in that enables you to make Volume Shadow Copy Service (VSS)-based backups of Exchange data using Windows Server Backup in Windows Server 2008. You can use Windows Server Backup to back up and restore your Exchange 2007 SP3 databases. A thorough understanding of what needs to be backed up, where to store backups, and how to restore backups is key to being an effective Exchange administrator. For more information about what needs to be backed up in Exchange 2007, see Using Windows Server Backup to Back Up and Restore Exchange Data.
Note
The Windows Server Backup program does not support the Exchange 2007 Extensible Storage Engine streaming APIs. It cannot be used to take streaming ESE backups of Exchange 2007.
Exchange-aware VSS backups are supported for both active storage groups and passive storage groups. The Exchange passive copy backup solution is a VSS-only solution. This solution is implemented by the Exchange Replica VSS Writer that is part of the Replication service. Streaming backups are only supported from active storage groups. Therefore, you cannot use the streaming backup APIs to back up a replica database. To back up a replica database, a VSS-aware backup program must be used together with the VSS Requestor for the Exchange Writer.
Note
The Windows Server Backup plug-in in Exchange 2007 SP3 does not support the Exchange Replica VSS Writer that is part of the Replication service. Therefore, it cannot be used to back up passive copies of storage groups.
Exchange 2007 supports running two separate VSS backup operations against the same Exchange server. Also, the Exchange 2007 Writer lets you restore Exchange data to an alternative location. This includes the Recovery Storage Group. The Exchange 2007 Writer also lets you restore database files to a folder that is not associated with a storage group. Then, you can use the JET database engine to replay transaction log files into the database to bring the database to a consistent and mountable state.
Note
In Microsoft Exchange Server 2003, you can use the streaming backup APIs to run two backups at the same time against two different storage groups. However, you cannot use VSS to perform these operations. In Exchange 2003, you cannot use VSS to back up a second storage group until after the backup for the first storage group finishes. Also, the Exchange 2003 Writer does not allow you to restore Exchange data to a path other than the original path.
To comply with Exchange 2007, VSS-based backup programs must meet these basic requirements:
The Exchange Writer must be used to back up the files.
Exchange 2007 includes a Writer that is built into the Exchange store.
The backup program must validate the shadow copy backup set.
The Exchange Writer must be used for any restore operations that restore files to their original locations.
The original location refers to an Exchange server that has the same name and the same file path as that of the server from which the VSS backup was taken.
These requirements help ensure the integrity and recoverability of shadow copy backups. If these requirements are not met, Microsoft Customer Service and Support (CSS) will consider the backup solution to be outside the Exchange VSS framework. In this case, Microsoft CSS cannot troubleshoot backup or restore issues. We recommend that you contact your backup solution vendor to verify that the backup program fulfills the requirements that are listed in this topic. For more details about these requirements, see "Exchange 2007 VSS Requirements" later in this topic.
Note
The vendor of the third-party backup program is the primary support provider for any backup or recovery issue that you may experience. Microsoft CSS can help diagnose or troubleshoot issues that you may experience with Exchange databases or transaction log files. However, Microsoft CSS is limited to helping you recover the database files and transaction log files that are available in your Exchange environment.
For more information about how VSS-based solutions are supported by Microsoft CSS, see Microsoft Knowledge Base article 841696, Overview of the Microsoft third-party storage software solutions support policy.
For More Information
Exchange 2007 VSS Requirements
The following sections describe the Exchange 2007 requirements that any shadow copy backup programs must follow to help ensure the integrity and recoverability of Exchange databases. These sections list specific Application events that help indicate whether the backup programs meet Exchange requirements. Backup programs and the Exchange server may log other events that are associated with the backup and restore process. To verify compliance with Exchange VSS requirements, confirm that the events are logged during the backup and restore operations.
Currently, there is no certification program for any third-party backup solution running on Exchange. Compliance with VSS helps to ensure the integrity and recoverability of shadow copy backups. However, it does not guarantee the performance or reliability of the third-party solution.
The Exchange Writer Must Be Used to Back Up the Files
The Exchange database files, transaction log files, and checkpoint files must be backed up exclusively through the Exchange Writer. The following events are logged in the Application log if the Exchange Writer is used during shadow copy backups:
Event Type: Information Event Source: ESE Event Category: ShadowCopy Event ID: 2005 User: N/A Computer: ServerName.contoso.com General: Information Store (2884) Shadow copy instance 5 starting. This will be a backup-type shadow copy. |
Note
In this event, backup type represents the kind of backup that you are performing. For example, backup type is Full, Copy, Incremental, or Differential.
Event Type: Information Event Source: MSExchangeIS Event Category: Exchange VSS Writer Event ID: 9608 User: N/A Computer: ServerName.contoso.com General: Exchange VSS Writer (instance GUID) has prepared for Snapshot successfully. |
Event Type: Information Event Source: MSExchangeIS Event Category: Exchange VSS Writer Event ID: 9610 User: N/A Computer: ServerName.contoso.com General: Exchange VSS Writer (instance GUID) has frozen the storage group(s) successfully. |
Event Type: Information Event Source: MSExchangeIS Event Category: Exchange VSS Writer Event ID: 9612 User: N/A Computer: ServerName.contoso.com General: Exchange VSS Writer (instance GUID) has thawed the storage group(s) successfully. |
The Backup Program Must Validate the Integrity of the Shadow Copy Backup Set
We recommend that the backup program validates the integrity of the shadow copy backup set before the backup program notifies Exchange that the backup has completed successfully. We recommend this for the following reason.
After a successful backup, Exchange performs the following two operations:
Exchange updates the headers of the backed up databases to indicate the last successful backup time.
Exchange truncates the transaction logs. In this scenario, Exchange removes the transaction log files that are no longer required to roll forward from the last successful backup.
Therefore, if a backup program postpones integrity verification until after Exchange has performed these tasks, you must take special care to preserve the last verified backup together with copies of all the transaction log files that are required by that particular backup. Although the backup may have already been reported as successful to Exchange, you should not rely on the backup until after the backup program has successfully completed the integrity verification operation.
For more information about how to perform an integrity check and about how to determine which database files and transaction log files must be preserved, see "Integrity Verification for VSS Backups" later in this topic.
The Exchange Writer Must Be Used for Any Restore Operations to the Original Location
The Exchange Writer must be used exclusively for any restore operations that restore Exchange-related files to their original locations. The original location is an Exchange server that has the same server name and the same file path as the Exchange server from which the VSS backup was taken.
The Exchange Writer logs the following events in the Application log during a shadow copy restore operation:
Event Type: Information Event Source: MSExchangeIS Event Category: Exchange VSS Writer Event ID: 9620 User: N/A Computer: ServerName.contoso.com General: Exchange VSS Writer (instance GUID) has processed pre-restore events successfully. |
Event Type: Information Event Source: MSExchangeIS Event Category: Exchange VSS Writer Event ID: 9618 User: N/A Computer: ServerName.contoso.com General: Exchange VSS Writer (instance GUID) has processed post-restore events successfully. |
Integrity Verification for VSS Backups
When you use the Exchange streaming backup API to back up a database, each page in the database is read in turn, and the checksum integrity of each page is verified during the backup process. The checksum integrity of transaction log files is also verified before the transaction log files are backed up.
However, during a VSS backup, there is no opportunity for Exchange to read each database file and to verify the checksum integrity. Therefore, database and transaction log file integrity must be verified by the backup program. You can run the Eseutil command to perform these verification checks.
If you do not perform checksum-verification of VSS backups, a damaged page could remain undetected in the database. The damaged page could eventually become present in all available backups. The only way to recover from this scenario is to repair the database. Database repairs may require extensive downtime and result in some data loss. You will lose the data that is on each damaged database page.
However, if you verify that the last VSS backup contains all good pages, you can purge damaged pages from the database. To do this, restore the verified backup and roll the backup forward by using the transaction logs that were created after the good backup occurred. The downtime that is required for this operation is generally much less than for a database repair operation. Also, you can perform this kind of recovery operation without data loss. Therefore, you should not consider a VSS backup to be successful until all the files in the backup have been checksum-verified.
We recommend that you use the following two rules to verify backup integrity:
You must always retain an integrity-verified copy of the database files. An integrity-verified backup is one in which page checksum verification has completed on the database file(s) in the backup set.
You must back up all transaction log files that are required to recover the most recent integrity-verified database file. Additionally, you must verify the checksum-level integrity of the transaction log files.
The required transaction logs include, at a minimum, the inclusive range of log files that are listed in the Log Required field in the header of each database file that is contained in the last verified backup. If these log files are not available, the database will not be mountable after it is restored.
Important
These requirements apply to the last integrity-verified backup and not to the most recent backup. Until the most recent backup has passed checksum verification, it is not considered to be a valid backup.
Optionally, you may also retain the additional transaction log files that are required to completely roll the database forward after you restore a database. These are all the transaction log files in an unbroken sequence, starting from the lowest Log Required file up to the most recently-created transaction log that has been purged from the Exchange server. Examples and explanations of these files appear below.
Preserving transaction log files beyond the ones that are listed in the Log Required range(s) is optional. However, it is only optional in the sense that retaining the log files is not strictly required to successfully restore and mount a backed up database. However, if you do not retain all the appropriate log files, restoring from backup will cause the loss of all changes in the database that occurred after the backup was taken.
We strongly recommend that you retain the transaction log files that are required to restore and mount a backed up database as well as all subsequent transaction log files that are required to roll the database forward.
To Determine Which Transaction Log Files Are Required
If an Exchange database is backed up while it is online, at least one transaction log file will always be backed up with it. This behavior occurs regardless of whether you use the streaming backup API or the VSS backup API.
After you restore an online backup, information from the transaction logs must be applied to the database. This operation is known as replaying the transaction log files. The Log Required field of each database header records the sequence (generation) numbers of the range of transaction log files that must be replayed into the database.
If the Log Required field displays 0-0, the database is mountable without having to replay any additional transaction log data. The only time that the Log Required value is 0-0 is after a database is brought into a clean-shutdown state. While a database is running, the Log Required field always records the range of transaction logs that have not yet been applied to the database. This range is updated continuously.
A database that is backed up in an online state always has a non-zero Log Required range. Therefore, the appropriate transaction log files must be backed up together with the database. If the log files are not available after you restore a database, the database will not be mountable. If you cannot obtain the required log files, you must perform a database repair operation. However, there is no guarantee that a database repair operation will be successful. Also, a database repair operation always results in some level of data loss, even if only the data in the missing log files is lost.
If you use the Exchange streaming backup API or the VSS backup API that is included with the Exchange Writer, the log files that are required to mount a database are automatically backed up with the database. If you replay only the log files that are specified in the Log Required field, the database will be restored to the point where the backup finished. If you want to roll the database forward past that point, you must also play the log files that were generated after the backup finished.
To completely roll the database forward from any particular backup, you must retain all the log files in an unbroken sequence, starting from the lowest log in the Log Required range up to the most recently generated log file in the database's storage group. If any log in this series is missing or damaged, you can only roll forward up to the point of the last good log file before the missing or damaged file.
Therefore, to experience no data loss when you recover from a backup, you must retain good copies of all the transaction log files going forward from the last verified good database backup.
Transaction Log Truncation
If transaction log files are not removed from an Exchange server, the log files accumulate until they fill all the available disk space. Therefore, both the streaming and VSS backup APIs support pruning transaction log files after the completion of a Normal backup or an Incremental backup. Log files that are older than those needed to recover the most recent backup are automatically deleted from the server after the backup program informs Exchange that the backup operation has completed successfully.
With the streaming API, checksum verification of the database is performed during the backup process. By the time the backup operation completes, the whole database and the required log files have been checked for physical integrity. With the VSS API, checksum verification cannot be performed as part of the actual backup process. The backup program vendor must verify the physical integrity of the database independently from the backup process. This verification can be performed by using the Eseutil command either before the backup operation or after the program informs Exchange that the backup has completed.
If checksum verification is performed before the backup completes and if a problem is found in the backup set, Exchange is signaled that the backup was unsuccessful. This action stops Exchange from truncating transaction log files from the server.
If checksum verification is postponed until after signaling the completion of a backup, Exchange deletes older log files from the server. Some of these log files may be required to roll forward from an earlier good backup. If you have not already made copies of these log files, you may not be able to roll forward completely.
We recommend that checksum verification be performed on a VSS backup before the backup program informs Exchange that the backup is complete. If checksum verification is postponed until after the backup has completed, the backup program must retain copies of all the transaction log files that are truncated, unless it is not important that you cannot roll forward Exchange completely.
In most cases, all the transaction log files that are required to roll a VSS backup forward are available in the set of log files that were saved with the previous backup together with the log files that are saved with the current backup. However, when you select a backup solution, you should verify that this is the case.
Restoring Unverified Backups
You may have to restore a database from a backup before checksum verification has been performed on the backup. In this scenario, we recommend that you restore the database from an earlier verified backup, and then roll that backup forward. This is preferred to relying on an unverified backup.
However, you may have a service level agreement that requires you to restore data more quickly than can be performed from earlier backups. In this scenario, restoring from an unverified backup may be a better option as long as you retain a previous verified backup together with all the log files that are required to roll forward completely from the previous backup. This lets you roll forward from a known good backup if you discover that the unverified backup is damaged.
Checking Snapshot Consistency
The VSS requestor must verify snapshot consistency. Also, verification of snapshot consistency is a requirement for a backup solution to be supported by the Exchange team. Exchange 2007 supports the following two methods to check snapshot consistency:
The CHKSGFILES API
The Eseutil command-line tool
For more information about how to verify snapshot consistency by using the CHKSGFILES API, see Validating Backup Integrity By Using CHKSGFILES.
For more information about how to verify snapshot consistency by using the Eseutil command-line tool, see Validating Backup Integrity By Using Eseutil.
Troubleshooting the Volume Shadow Copy Service
By default, VSS is installed with Windows Server 2008. The service is set to a Manual startup type. The service starts if a backup program (the Requestor) can use the VSS Writer or Writers.
You can use the following items to help troubleshoot an issue that you may experience with Exchange 2007 VSS backups:
Event log information
VSSADMIN commands
Diagnostic logging
The Exchange Extra tool
The BETest tool
Event Log Information
The following steps describe the Exchange 2007 backup process that occurs when you use VSS together with the corresponding events that are logged. Examine the events that are logged during the backup operation to help determine which component is failing.
Step 1: Database Preparation
The backup program, also known as the agent, runs a scheduled job.
The VSS Requestor in the backup program submits a request to VSS to prepare the selected Exchange storage groups for a snapshot backup.
VSS signals the Exchange VSS Writer to prepare for a snapshot backup.
The following table lists the series of events that are logged in the Application log for every backup instance that is started.
| Event ID | Event Type | Event Source | General |
|---|---|---|---|
9604 |
Information |
MSExchangeIS |
Exchange VSS Writer has successfully collected the metadata document in preparation for backup or restore. |
9818 |
Information |
MSExchangeIS |
Exchange VSS Writer (instance 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56) has been called for "EcPrepareSGForBackup." Data: 0000: 54 68 69 72 64 20 53 74 Third St 0008: 6f 72 61 67 65 20 47 72 orage Gr oup. |
9811 |
Information |
MSExchangeIS |
Exchange VSS Writer (instance 56) has successfully prepared the database engine for a full or copy backup of storage group 'Third Storage Group'. The following 1 databases are mounted and will be backed up: Third Storage Group Data: 0000: 46 75 6c 6c 00 Full. |
9606 |
Information |
MSExchangeIS |
Exchange VSS Writer (instance 097f686a-7ffb-4903-935f-1b1b1a0d3a27) has prepared for backup successfully. |
9818 |
Information |
MSExchangeIS |
Exchange VSS Writer (instance 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56) has been called for "CVssIExchWriter::OnPrepareSnapshot". |
9608 |
Information |
MSExchangeIS |
Exchange VSS Writer (instance 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56) has prepared for Snapshot successfully. |
2005 |
Information |
ESE |
Information Store (2256) Shadow copy instance 56 starting. This will be a Full shadow copy. |
Step 2: Database Snapshot
After the Exchange Writer reports to VSS that the backup preparation is complete, the following actions occur:
The Exchange Writer freezes the appropriate Exchange databases. In this scenario, Exchange performs the following operations.
Exchange prohibits administrative actions against the particular storage group.
Exchange checks volume dependencies for the storage group.
Exchange suspends all write operations to the appropriate database files and transaction log files.
Note
Exchange still allows Read access to the database files and transaction log files.
When Exchange starts the operation to freeze the Exchange database files and transaction log files, Exchange starts a worker thread to keep track of how long it takes to create the snapshot copy of the database. The copy process is not permitted to take longer than 10 seconds.
The whole snapshot copy process may not exceed 70 seconds. This includes all the operations that occur in the "Step 2: Database Snapshot" process. If the whole process exceeds 70 seconds, the worker thread times out. If a time-out occurs, Exchange stops the backup job and unfreezes the Exchange storage groups. Then, Exchange continues typical operations.
The following table lists the series of events that are logged in the Application log during the snapshot operation.
| Event ID | Event Type | Event Source | General |
|---|---|---|---|
2001 |
Information |
MSExchangeIS |
MSExchangeIS (2256) Third Storage Group: Shadow copy instance 56 freeze started. |
9818 |
Information |
MSExchangeIS |
Exchange VSS Writer (instance 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56) has been called for "CVssIExchWriter::OnFreeze". |
9610 |
Information |
MSExchangeIS |
Exchange VSS Writer (instance 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56) has frozen the storage group(s) successfully. |
9818 |
Information |
MSExchangeIS |
Exchange VSS Writer (instance 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56) has been called for "CVssIExchWriter::OnThaw" |
2003 |
Information |
ESE |
Information Store (2256) Shadow copy instance 56 freeze ended. |
9612 |
Information |
MSExchangeIS |
Exchange VSS Writer (instance 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56) has thawed the storage group(s) successfully. |
9818 |
Information |
MSExchangeIS |
Exchange VSS Writer (instance 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56) has been called for "CVssIExchWriter::OnPostSnapshot" |
Step 3: Shadow Copy Verification
The VSS Requestor in the backup program verifies the health of the shadow copy. Then, the program informs Exchange whether the backup was successful. This action signals the completion of the backup operation. The OnBackupComplete() method is used to reset the backupInProgress flag.
The following table lists the series of events that are logged in the Application log during the completion of the backup:
| Event ID | Event Type | Event Source | General |
|---|---|---|---|
9818 |
Information |
MSExchangeIS |
Exchange VSS Writer (instance 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56) has been called for "CVssIExchWriter::OnBackupComplete". |
9818 |
Information |
MSExchangeIS |
Exchange VSS Writer (instance 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56) has been called for "EcSGBackupComplete". Data: 0000: 54 68 69 72 64 20 53 74 Third Storage Group. |
9780 |
Information |
MSExchangeIS |
Exchange VSS Writer (instance 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56) has successfully completed the full or incremental backup of storage group 'Third Storage Group'. |
2006 |
Information |
ESE |
Information Store (2256) Shadow copy instance 56 completed successfully. |
9616 |
Information |
MSExchangeIS |
Exchange VSS Writer (instance 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56) has processed the backup completion event successfully. |
When the backup operation exits, the Exchange Writer calls the OnBackupShutdown() method. This method is used to perform operations that are required when a backup program exits after the backup job is finished.
If a fatal error has occurred, the OnBackupShutdown() method sets the Exchange Writer status to Failed.
The following table lists the series of events that are logged in the Application log during a BackupShutdown event.
| Event ID | Event Type | Event Source | General |
|---|---|---|---|
9818 |
Information |
MSExchangeIS |
Exchange VSS Writer (instance 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56) has been called for "CVssIExchWriter::OnBackupShutdown". |
9648 |
Information |
MSExchangeIS |
Exchange VSS Writer (instance 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56) has processed the backup shutdown event successfully. |
The following two function calls occur during a backup failure:
CVssIExchWriter::OnAbort()
This method indicates that a shadow copy operation has ended prematurely. The Exchange Writer uses this method to clean up the Exchange Writer and to tell the JET database to thaw (release) the information store. Also, the Exchange Writer uses this method to tell the JET database that the snapshot was stopped.
CVssIExchWriter::EcBackupCleanup()
If the backup has failed, Exchange uses this method to perform post-backup failure cleanup operations. Exchange uses this method to tell the JET database that the snapshot has failed. Also, Exchange uses this method to tell the information store that the snapshot has failed.
Step 4: Transaction Log Truncation
At the end of a successful backup, Exchange performs the following operations:
Exchange truncates the transaction log files.
Note
If you do not perform an Exchange backup but instead take a snapshot backup of a volume that contains Exchange database files, the backup is handled in the same manner as for an Exchange backup. However, in this scenario, the backup is considered to be a Copy backup, and no transaction log truncation occurs.
Exchange updates the database headers with the appropriate Log Required field information.
Exchange clears the backup in progress status.
Exchange records the time of the last backup for the appropriate databases.
VSSADMIN Commands
You can use the VSS administrative command-line tool (VSSADMIN) to obtain information about the Writers and Providers that are registered with VSS.
To obtain information about VSS Writers, follow these steps:
On the Exchange server, click Start, click Run, type cmd, and then click OK.
At the command prompt, type vssadmin list writers, and then press ENTER.
Examine the results that are returned to locate the Exchange Writer results. The Exchange Writer should be in a stable state. The following results are returned when the Exchange Writer is in a stable state:
Writer name: 'Microsoft Exchange Writer'
Writer Id: {76fe1ac4-15f7-4bcd987e-8e1acb462fb7}
Writer Instance Id: {977637c2-fcdd-463e-b1f8-a9a5d603a2e8}
State: [1] Stable
Last error: No error
If the State value is anything other than Stable, restart the Microsoft Exchange Information Store service. Results that resemble the following are returned when the Exchange Writer is in a failed state:
Writer name: 'Microsoft Exchange Writer'
Writer Id: {76fe1ac4-15f7-4bcd987e-8e1acb462fb7}
Writer Instance Id: {977637c2-fcdd-463e-b1f8-a9a5d603a2e8}
State: [14] Failed
Last error: Retryable error
To obtain information about the registered VSS Providers, type vssadmin list providers at the command prompt. The following results should appear:
Provider name: 'Microsoft Software Shadow Copy provider 1.0'
Provider type: System
Provider Id: {b5946137-7b9f-4925-af80-51abd60b20d5}
Version: 1.0.0.7
By default, only the Microsoft Software Shadow Copy provider is listed. However, if a third-party backup program is installed, other providers may be listed.
Note
For more information about the commands that are available, type vssadmin /? at the command prompt.
Diagnostic Logging
If you suspect that the issue that you experience is caused by an issue with the Exchange Writer, enable diagnostic logging for the Exchange Writer. To do this, follow these steps:
Start the Exchange Management Shell.
Run the following command:
get-eventloglevel | where-object {$_.identity -like "*Exchange Writer*"} | set-eventloglevel -level expertTo verify the logging level for the Exchange Writer, run the following command:
get-eventloglevel | where-object {$_.identity -like "*Exchange Writer*"}To restore the diagnostic logging level to its default level, run the following command:
get-eventloglevel | where-object {$_.identity -like "*Exchange Writer*"} | set-eventloglevel -level Lowest
The Exchange 2007 Extra Tool
You can use the Troubleshooting Assistant (Extra) tool that is included with Exchange 2007 to trace the Exchange Writer. To do this, follow these steps:
On the Exchange server, click Start, click Run, type extra, and then click OK.
If you have not run the program previously, click Join the Microsoft Customer Experience Improvement Program, or click I don't want to join the program at this time.
In the task pane, click Select a task.
On the Troubleshooting Task Selection screen, click Trace Control.
If you receive the following message, click OK:
This server does not have the module needed for interpreting traces. Proceed only if this is being done under the direct supervision of a qualified Exchange support engineer.
Note the path that is displayed in the Select trace file location box.
Click Set manual trace tags.
In the Components to Trace list, click Store, but do not click to select the Store check box.
In the Trace Tags list, click to select the tagVSS check box.
Click Start Tracing.
The BETest Tool
You can use the BETest tool to help determine whether an issue is caused by a third-party VSS Requestor.
The BETest tool is a test Requestor that you can use to test the Exchange VSS Writer. The BETest tool uses the Microsoft VSS API to communicate with and to test the Exchange Writer. The BETest tool can perform many of the tasks that a typical VSS Requestor performs. You can use the BETest tool to take a VSS backup of an Exchange storage group. BETest can take a VSS snapshot of an active database or a replica database on an Exchange 2007 server.
To obtain this tool, download and install the VSS SDK, version 7.2. To obtain this SDK, see Volume Shadow Copy Service SDK 7.2.
The following path is the default installation location for the i386 version of BETest:
C:\Program Files (x86)\Microsoft\VSSSDK72\TestApps\betest\obj\i386
Note
An AMD64 version of BETest is also available. Before you run BETest, move to the directory that contains the appropriate operating system version.
To use BETest, follow these steps:
Open a command prompt, and then move to the appropriate directory for your operating system. For example, move to the C:\Program Files (x86)\Microsoft\VSSSDK72\TestApps\betest\obj\amd64 directory.
Verify which VSS Writers are available. To do this, start a command prompt, and then run the following command:
vssadmin list writersCreate a Components.txt file for use with BETest. To do this, follow these steps:
Obtain the GUID of the Exchange writer. To do this, examine the output from the vssadmin list writers command that you entered in step 2.
Obtain the GUID from the appropriate storage group. To do this, start the Exchange Management Shell, and then run the following command:
Get-StorageGroup -server <ServerName> | fl name, guidIn this command, <ServerName> represents the name of the server on which you will run the BETest tool.
Use the results from the Get-StorageGroup command to populate a Components.txt file. This file has the following format:
"<WriterIdGUID>": "<component-logical-path>" {"target" # "new target", ...}, ..."<component-logical-path>" : "<subcomponent-logical-path>,...";
In this file, <component-logical-path> represents the LogicalPath entry, the LogicalPath entry together with the component GUID, or, if no LogicalPath value exists, only the component GUID. The component GUID represents a particular storage group. For example, the <component-logical-path> entry might be "Microsoft Exchange Server\Microsoft Information Store\ServerName\000dd565-c4e8-4f58-a8b1-2e29eee4f5c0."
The following is a sample Components.txt file:
"{76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}":"Microsoft Exchange Server\Microsoft Information Store\ServerName\999dd565-c4e8-4f58-a8b1-2e29eee4f5c0";
In this example, the first GUID is that of the Exchange Writer. You cannot modify this GUID. The second GUID belongs to a particular storage group. You can specify the storage group that you want to run the command against by specifying the GUID of the appropriate storage group. To obtain the GUID for a particular storage group, run the Get-StorageGroup '<StorageGroupName>' | fl GUID cmdlet.
Exchange only supports streaming backups against active storage groups. Therefore, to back up a passive storage group, you must use a VSS backup. If you have an Exchange Continuous Cluster Replication (CCR) cluster or if you want to back up the replica copy from a server that is enabled for Local Continuous Replication (LCR), the Components.txt file must resemble one of the following examples.
For a CCR passive copy
"{76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}":"Microsoft Exchange Server\Microsoft Information Store\Replica\<Clustered Mailbox Server Name>\<Storage Group GUID>";
For an LCR passive copy
"{76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}":"Microsoft Exchange Server\Microsoft Information Store\Replica\<Server Name>\<Storage Group GUID>";
After you create the Components.txt file, run the following command to back up the storage group:
BETEST.exe /B /E /T 1 /S output.XML /C components.txt /D c:\betest > output.txtNote
This command creates the backup in the C:\Betest directory. You can also run this command without the /E option.
If you receive an error message when you run the command, a problem exists with the Exchange Writer. To help troubleshoot the issue, examine the contents of the Output.txt file that was created when you ran the command in step 4.
Best Practices
The following list contains some of the recommended best practices to troubleshoot VSS backup issues:
Verify that you have installed the latest Windows service packs and the latest VSS updates.
Assume that you are troubleshooting a -2403 error that occurs when you try to start a backup job. In this case, VSS uses a Manual startup type. If a backup job hangs, VSS may not stop. Instead, VSS may determine that the backup is still running. In this scenario, you receive a -2403 error when you try to start a new backup job. To resolve this issue, manually stop VSS, and then start the backup job.
If you use the BETest program to troubleshoot an issue, use the program to capture multiple BETest backups over a period of many days. Also, when you run the BETest program, you should stop and temporarily disable any third-party backup-related services.
If you experience time-out issues with the VSS Writer, you may be experiencing performance issues on the server. In this scenario, collect performance logs to determine whether a performance issue exists.
The VSS Writer is in a Retryable state. This issue indicates that the VSS Writer experienced a non-fatal error. The state automatically changes after some time. However, you can resolve the Retryable state issue by restarting the server.
VSS References
The following VSS-related references are available: