What Is VSS?
VSS is a set of COM APIs that implements a framework that enables volume backups to be performed while applications on a system continue to write to the volumes. Requestors, writers, and providers communicate in the VSS framework to create and restore volume shadow copies. A shadow copy of a volume duplicates all the data held on that volume at one well-defined instant in time.
The backup process includes the following steps:
1. The requestor initiates the backup process. The requestor instructs the writer to prepare a data set for backup.
2. The writer prepares the data for backup. Exchange Server 2003 and other applications implement writers that prepare data according to the specific requirements of the application. After the data set is ready, the writer signals the requestor to back up the data set.
3. The provider interacts with the disk system and manages shadow copies. When instructed by the requestor, the provider creates a shadow copy.
4. The requestor signals backup success or failure to the writer, and completes the backup process.
By separating the functionality of requestors, writers, and providers, the VSS framework makes each component independent of the others. A single requestor can interact with different providers or with multiple writers. For more information about requestors, writers, and providers, see Basic VSS Concepts.
The Exchange writer is automatically installed with Exchange Server 2003. Requestors can access the Exchange writer only if Exchange Server 2003 is installed on the Windows Server 2003 operating system. VSS backups are not available for Exchange Server 2003 if Exchange Server 2003 is installed on Microsoft Windows? 2000 Server.
When instructed to do so by a requestor, the Exchange writer prepares Exchange databases for backup. The writer does this by suspending all disk write I/O to the databases for up to 20 seconds. This is referred to as freezing the databases. The provider must be able to complete the shadow copy within this window or the backup will be aborted. After backup finishes, the writer thaws the databases and resumes regular I/O operations.
Note:
Windows Backup for Windows Server 2003 can use the default software-based Windows VSS provider to perform generic VSS backups of disk volumes and files. However, Windows Backup cannot communicate with the Exchange writer and should not be used to make VSS backups of Exchange database files. Several non-Microsoft backup applications implement requestors that work with the Exchange writer.
VSS Backup Methods
A provider can execute shadow copy requests in many different ways. Although the Exchange writer is not aware of how the provider is creating a shadow copy, make sure that you understand how the provider for your solution works so that you can plan for performance and capacity. Although no industry-standard definition or naming convention for shadow copy backup methods exists, the large majority of backup methods can be broadly categorized as either clone shadow copies or snapshot shadow copies.
Clone Shadow Copies
A clone shadow copy is a full copy of the volumes in a shadow copy set. A shadow copy set is a group of volume shadow copies that are synchronized at the same point in time.
Like an ordinary copy, a clone is independent of the original data. If all the original data is lost, the clone still persists intact. This differs from a snapshot, which is not fully independent of the original data. For more information about snapshots, see "Snapshot Shadow Copies" later in this article.
You must consider capacity planning when you use clones. To make sure that a restorable copy is available if a failure occurs during a backup, you must use an N+1 scheme, where N is the number of backup clones that you want to have available to restore at any time. For example, if you decide to have only one backup, you still need two (1+1) target clones to rotate between to prevent data loss if a failure occurs during a backup.
* The provider vendor determines how a particular solution implements how a clone is created.
Mirror Some solutions prepare mirror copies in advance. These mirror copies are then split off to take a backup, providing you with a read-only copy and a live production volume. This strategy has almost no affect on the production logical unit numbers (LUNs) during the backup and checksum integrity process. However, it does create significant I/O load on production LUNs before the backup.
You must make sure that you schedule time to resynchronize a clone that is no longer needed with the production LUN when you rotate through multiple clones. For restoration, the solution might resynchronize the read-only copy to the production LUN, which affects any other online storage groups that are using the same production LUN until all the data is copied. During restore, some storage arrays just change pointers to the read-only copy. This makes it writable.
Clone Some solutions create a clone at the time of backup, where all the data in the LUN must be copied to another LUN. That data is then marked read-only. This strategy can consume less capacity up front, but requires all data to be copied at the time of backup. With this strategy, you must know how many gigabytes per hour a particular storage controller can sustain, in addition to the effect on the production database LUNs during the copy. This enables you to design your LUNs correctly for maximum throughput, and to plan the timing of this operation to minimize the effect on the production LUNs.
Snapshot Shadow Copies
The most important difference between a clone and a snapshot is that a snapshot is not fully independent of the original data. Generically, snapshots are created by defining a marker at a point in time and making sure that the data can be rolled back to that point in time. You can keep multiple snapshots, and snapshots typically require much less additional disk space than clones.
Snapshots can be created in several different ways. The most common method is called copy-on-write.
The copy-on-write method defines a snapshot at a point in time, and then monitors the original dataset for changes. If a change is made, the change is recorded or tracked in a separate location. Over time, therefore, the size of a snapshot can continue to grow, especially when a snapshot is made of a quickly changing dataset.
The snapshot manager presents different views of the dataset, typically as if they were different full backups of the data. The snapshot manager can also switch to any available view of the data on demand, thus, in a sense, restoring the data.
Remember that a snapshot is not actually an independent copy of the data. If the original data is destroyed, the snapshot data is useless because it contains only the recent changes to the data.
This backup method gives you a rollback mechanism, but not an actual backup of the data. The advantage to this backup method is that you are only writing the changes, instead of all the data, to disk, so that the actual creation of the snapshot can occur very quickly. A disadvantage is that you do not have a recoverable backup if your original data is corrupted.
Because a snapshot backup does not provide a true backup, most solutions implement an additional step that streams the snapshot backup to tape. Streaming to tape adds a significant sequential I/O load to your production database LUNs.
During regular operation, the I/O pattern for a disk hosting Exchange databases is very random, but the I/O pattern for a streaming backup is very sequential. Mixing sequential workloads with random workloads makes it harder for caching to continue to be efficient and can lead to excessive latency and reduce peak I/O throughput considerably. This is an important factor to consider if you plan to depend completely on snapshots as your backup source for Exchange Server 2003.
Many Exchange Server administrators plan to reduce the effect of this problem by performing streaming backups during off-peak hours. Although this can be an effective strategy, it might not be obvious what the off-peak hours actually are.
Besides responding to client requests, an Exchange database also requires time to perform online maintenance. This maintenance can be scheduled by the administrator, but frequently requires several hours a day to finish. Even if end-user load is low, the database might be busy with maintenance tasks. You must also consider the additional server load required to prepare or perform backups. As a best practice, avoid overlapping backup windows with online maintenance or peak user demand intervals.
To determine what peak hours are for database activity, you have to actually profile the load on your databases over a baseline period of at least several days.
Exchange Requestors and Checksum Integrity Verification
An Exchange database file is divided into a series of pages of equal size. Each of these pages contains a checksum that verifies the integrity of the Exchange data on that page. If any data on the page is changed outside the control of the Exchange server, for example, by a disk or controller error, verification of the checksum will detect this problem. Exchange transaction log files also implement a checksumming scheme, but one that is not page-based. Therefore, damage to transaction log files can also be detected.
Microsoft supports a streaming backup API for performing backups of Exchange databases when they are running. The streaming API is implemented in Windows Backup on all versions of Windows and Exchange Server and in many non-Microsoft backup applications.
Note:
You must install the Exchange administrator program on a computer that is running Windows Server in order to enable Windows Backup to perform Exchange online streaming API backups.
Essentially, a streaming backup copies a database to the backup media one page at a time, in order. During backup, the checksum of each page is verified, and the backup is completed successfully only if all pages in the database pass verification. Transaction log files that are part of the backup are also verified. This guarantees that the last backup of a particular database is a good one.
There is no opportunity to verify page integrity of a database or transaction logs as a shadow copy is created. Therefore, checksum integrity verification must be performed after the shadow copy has been created. Microsoft guidelines put responsibility for performing this verification on the requestor.
The requestor, or backup application, runs checksum integrity verification against the database and log files after the backup is completed. This is a very heavy streaming I/O load against the database and transaction log logical unit numbers (LUNs). The requestor performs the checksum integrity verification by running Exchange Server Database Utilities (Eseutil.exe). This reads the whole set of backup files to verify the individual integrity of each database page and transaction log file.
By default, Eseutil.exe runs as fast as the storage can read the data, and this is optimal for the typical clone, which is independent of the production LUNs. However, not all VSS backup sets are independent of the original data. For more information about different types of VSS backups, see ?VSS Backup Methods? later in this article.
Sometimes, it may help to throttle the I/O rate of the checksum integrity verification by adding an artificial pause after a set number of I/Os. By using Exchange Server 2003 with Service Pack 2 (SP2), you can add the following switch to add a 1 second pause after a set number of I/Os:
/p
Where x indicates the number of I/Os after which the pause occurs. For example, the following command adds an artificial 1 second pause after every 100 I/Os:
Copy Code
eseutil /K /p100
This I/O throttling is implemented only for database file verification, not for transaction log file verification.
You must carefully consider and plan for the I/O load created by checksum integrity verification when devising your backup procedures. This verification is an important part of the backup process and cannot be disregarded. However, you can defer the verification temporarily, subject to strict guidelines described in the Microsoft Knowledge Base article 822896, Exchange Server 2003 Data Backup and Volume Shadow Copy Services. This article provides a detailed description of the checksum integrity verification requirements that must be met by a backup requestor for it to be in compliance with Microsoft supportability recommendations.
A snapshot cannot be fully independent of the production LUNs. Therefore, running checksum verification for a snapshot must have an effect on the production LUNs. Checksum verification on a clone might or might not affect the production system, depending on where the clone is stored and how it is accessed.
You must carefully monitor the I/O load and effect of the verification process on both your end users and on ordinary database maintenance. Careful use of the Eseutil.exe throttling mechanism might also let you better balance verification performance with other I/O demands.
http://technet.microsoft.com/en-us/library/aa996004(EXCHG.65).aspx
Please post back if you have any more problems or questions.
