For More Information

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:

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.

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 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:

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.

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.

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.

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.

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

Step 2: Database Snapshot

Step 3: Shadow Copy Verification

Step 4: Transaction Log Truncation

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:

1. On the Exchange server, click Start, click Run, type cmd, and then click OK.
   
   
2. 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

3. 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.

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:

1. Start the Exchange Management Shell.
   
   
2. Run the following command:
   
   

   	Copy Code
   get-eventloglevel | where-object {$_.identity -like "*Exchange Writer*"} | set-eventloglevel -level expert

3. To verify the logging level for the Exchange Writer, run the following command:
   
   

   	Copy Code
   get-eventloglevel | where-object {$_.identity -like "*Exchange Writer*"}

4. To restore the diagnostic logging level to its default level, run the following command:
   
   

   	Copy Code
   get-eventloglevel | where-object {$_.identity -like "*Exchange Writer*"} | set-eventloglevel -level Lowest

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:

1. On the Exchange server, click Start, click Run, type extra, and then click OK.
   
   
2. 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.
   
   
3. In the task pane, click Select a task.
   
   
4. On the Troubleshooting Task Selection screen, click Trace Control.
   
   
5. 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.

6. Note the path that is displayed in the Select trace file location box.
   
   
7. Click Set manual trace tags.
   
   
8. In the Components to Trace list, click Store, but do not click to select the Store check box.
   
   
9. In the Trace Tags list, click to select the tagVSS check box.
   
   
10. Click Start Tracing.
    
    

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:

1. 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.
   
   
2. Verify which VSS Writers are available. To do this, type betest.exe >AvailableWriters.txt.
   
   
3. Create a Components.txt file for use with BETest. To do this, follow these steps:
   
   
   1. Open the AvailableWriters.txt file by using a text editor, such as Notepad.
      
      
   2. Locate the Microsoft Exchange Writer section. In Notepad, press F3, type Microsoft Exchange Writer in the Find what box, and then click Find Next.
      
      
   3. Use the information that appears in the WriterName = Microsoft Exchange Writer section 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>";

4. After you create the Components.txt file, run the following command to back up the storage group:
   
   

   	Copy Code
   BETEST.exe /B /E /T 1 /S output.XML /C components.txt /D c:\betest > output.txt

   Note:
   This command creates the backup in the C:\Betest directory. You can also run this command without the /E option.

5. 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.