An Introduction to the Principles of Volume Shadow Copy Service (VSS)

Microsoft Exchange Server 2003 utilizes the Volume Shadow Copy Service included in the Microsoft Windows Server 2003 operating system to generate shadow copies of Exchange Server 2003 databases and log files. By employing VSS, you may be able to recover the database within minutes, regardless of its size. The speed of recovery primarily depends on the capabilities of the provider components in the VSS solution.

Due to the availability of numerous Volume Shadow Copy Service strategies, it is essential to understand and test the capacity, performance, and recovery of your chosen scheme to ensure that the required data can be successfully recovered in your deployment. You must also verify the feasibility of any potential schemes within the VSS framework. The following section will describe the selection, testing, deployment, and monitoring of VSS solutions for Exchange Server 2003.

What is VSS?

VSS is a COM API that deploys an architecture enabling volume backups to be performed while applications on the system continue writing to the volumes. Requesters, writers, and providers communicate within the VSS architecture to create and restore volume shadow copies. A shadow copy of a volume replicates all the data loaded on the volume in its normal state in a timely manner.

Backup process steps

1. The requester starts the backup. Next, the requester notifies the writer to prepare a dataset for backup.

2. The writer prepares data for backup. Exchange Server 2003 and other applications deploy a writer to prepare data according to the specific requirements of the application. Once the data set is ready, the writer signals the requester to back up the dataset.

3. The provider program interacts with the disk system and manages shadow copies. The provider program creates shadow copies when instructed to do so by the requester.

4. The requester signals the success or failure of the backup to the writer, and then completes the entire backup process.

5. By separating the functions of requesters, writers, and providers, the Microsoft Volume Shadow Copy Service architecture makes each component independent of the others. A requester is able to interact with different provider programs or multiple writers.

The Exchange Writer is automatically installed with Exchange Server 2003. Requesters can access the Exchange Writer only when Exchange Server 2003 is installed on the Windows Server 2003 operating system. Microsoft Volume Shadow Copy Service backups will not be available for Exchange Server 2003 if it is installed on Microsoft Windows 2000 Server.

When instructed to do so by requesters, the Exchange Writer prepares the Exchange database for backup. The writer accomplishes this by pausing all disk write I/O to the database for up to 20 seconds. This is also known as freezing the database. The provider must be able to complete the shadow backup within this window; Otherwise, the backup will fail. After the backup is completed, the writer unfreezes the database and normal I/O operations are resumed.

Note

Windows Backup for Windows Server 2003 can perform normal Microsoft Volume Shadow Copy Service backups of disk volumes and files using the default software-based Windows VSS provider. 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 deploy requesters that work with the Exchange writer.

VSS backup method

Providers can perform shadow backups in many ways. Although Exchange writers do not know how providers create shadow copies, make sure you understand how the providers in your scenario work so you can plan for performance and capacity. Although there is no industry standard definition or naming convention for existing shadow copy backup methods, most backup methods can be categorized in general as either clone shadow copies or snapshot shadow copies.

What is clone shadow copy?

In a shadow copy set, cloning a shadow copy results in a complete copy of the volume. A shadow copy set is a group of volume shadow copies that are synchronized at the same point in time.

Like a regular copy, a clone is independent of the original data. If all the original data is lost, the clone remains unchanged. This is different from a snapshot, which is not entirely independent of the original data.

When using clones, you must consider capacity planning. To ensure recoverability in case of a failure during backup, you need to employ an N+1 strategy, where N represents the number of backup clones you want to have available for recovery at any given time. For example, if you decide to have only one backup clone, you still need two (1+1) target clones to rotate and prevent data loss in case of a failure during backup.

Cloning deployment strategy

The cloning deployment strategy is determined by the software vendor. Some approaches involve preparing images in advance before backups, and then splitting them into two copies. One of these copies serves as a read-only replica for backup purposes, while the other is retained within the volume of the production environment. This strategy has minimal impact on the logical units (LUNs) in the production environment during backup, validation, and integrity checks. However, it increases the I/O load on LUNs in the production environment before the backup process. It is essential to ensure the re-synchronization of logical units that are no longer required between multiple clones to prevent backup failures.

Some strategies involve creating clones during backups, where all the data in the volume must be copied to another LUN. Subsequently, this data is marked as read-only. This strategy may require less capacity but necessitates copying all data during backups. Some strategies involve creating clones during backups, where all the data in the volume must be copied to another LUN. Subsequently, this data is marked as read-only. This strategy may require less capacity but necessitates copying all data during backups. With this strategy, it is crucial to know how many gigabytes per hour a specific storage controller can maintain to properly design LUNs for maximum throughput and schedule backups to minimize the impact on production LUNs.

What is a snapshot shadow copy?

The most important difference between clones and snapshots is that snapshots are not completely independent of the original data. Generally, snapshots are created by defining a tag at a point in time while ensuring that the data can be rolled back to that point in time. You are able to maintain multiple snapshots, and snapshots require less space than clones.

Snapshot Manager provides different views of the dataset, often as if they were different full backups of the data. As needed the Snapshot Manager is also able to switch to any available view of the data so that, in a sense, the data is restored.

Remember that snapshots are not really backups independent of the data. Snapshot data is useless if the original data is corrupted because it contains only the most recent modifications to the data.

This backup method gives you the mechanism to roll back, but is not a true backup of your data. The advantage of this backup method is that you only write the changes, not all the data, to disk, so the actual creation of the snapshot happens very quickly. The disadvantage is that you don't have a recoverable backup if your original data is corrupted.

Because snapshot backups do not provide a true backup, most solutions deploy an extra step to stream the snapshot backup to tape. Streaming to tape adds significant sequential load to the I/O of your production database LUNs.

During regular operation, the I/O load is very random for the disks loading the Exchange database, but very continuous for streaming backups. The mix of continuous and random loads makes it difficult for the cache to remain efficient and can cause additional latency and a significant reduction in maximum throughput. This is an important factor to consider if you plan to rely exclusively on snapshots as your backup source for Exchange Server 2003.

Exchange requester and checksum integrity check

The Exchange database file is divided into a series of equally sized pages. Each of these pages contains checks that verify the integrity of the Exchange data on the page. If any of the data on a page is changed outside of the Exchange server's control, for example, by a disk or controller error, the checksum will detect the problem.The Exchange transaction log file also deploys a checksum scheme, but it is not page-based. Therefore, corruption of the transaction log file can also be detected.

Microsoft supports the streaming backup API to perform backups of Exchange databases while they are running. The Streaming API is deployed in Windows Backup on all versions of Windows and Exchange Server, as well as in many non-Microsoft backup applications.

Note: You must install the Exchange manager on the computer running Windows Server to allow Windows Backup to perform Exchange online streaming API backups.

Essentially, a streaming backup copies the database one page at a time as it is copied to the media, which is pretty neat. During the backup, the checksum is validated for each page and the backup is only successfully completed when all pages in the database pass validation. The transaction log file is also validated during the backup. This ensures that the last backup of a particular database is good.

There is no opportunity to verify the page integrity of the database or the transaction log when the shadow copy is created. Therefore, checksum integrity checks must be performed after the shadow copy is created. Microsoft guidelines provide the responsibility for performing this validation on the requestor.

The requester, or backup application, runs checksum integrity checks on the database and log files after the backup is complete. This is a very heavy streaming I/O load on the database and transaction log logical unit numbers (LUNs). The requester performs checksum integrity checks by running the Execute Exchange Server Database Tool (Eseutil.exe). It reads the entire backup fileset to verify the individual integrity of each database page and transaction log file.

By default, Eseutil.exe runs as fast as the store reads the data, which is optimal for a typical production LUN-independent clone. However, not all Microsoft Volume Shadow Copy Service backup sets are independent of the original data.

By using Exchange Server 2003 with Service Pack 2, you can add the following switch to add a 1-second pause after a set of I/O numbers.

/p

The x here indicates the number of I/Os after which the pause will occur. For example, the following command adds a 1-second pause after every 100 I/Os:

eseutil /K /p100

The I/O slowdown deployment is only for database file validation and does not apply to transaction log file validation.

Snapshots are not completely independent of production LUNs. so running checksums on snapshots will definitely affect production LUNs. Checksums on clones may or may 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 the impact of the validation process on your end users and normal database maintenance.

Effortless VM data protection with Vinchin Backup & Recovery

In addition to the flexibility of using Volume Shadow Copy Service backups, data can also be protected with virtualization technology. VM backups are becoming increasingly popular because of their flexibility, scalability and efficiency.

Vinchin Backup & Recovery is a backup solution designed for virtual machines of VMware, Hyper-V, XenServer, XCP-ng, oVirt, RHV, etc. It provides comprehensive and powerful VM backup and recovery features like agentless backup, instant recovery, V2V migration designed to protect and manage critical data in the virtualization environment.

Vinchin Backup & Recovery’s operation is very simple, just a few simple steps. 

1. Just select VMs on the host

2. Then select backup destination 

3. Select strategies

4. Finally submit the job

Vinchin offers a free 60-day trial for users to experience the functionality in a real-world environment. For more information, please contact Vinchin directly or contact our local partners.

Conclusion

In summary, Volume Shadow Copy Service is an important component in Microsoft Exchange Server 2003 that enables efficient database recovery. Different VSS policies must be carefully evaluated and tested to ensure optimal performance and recovery within the server framework.