I.

Introduction
IBM Tivoli Storage Manager for Copy Services (CS) provides low-impact backups and very quick restores of business-critical database, messaging, and collaboration data. This storage management solution meets the continuous availability requirements demanded by today's businesses by exploiting Microsoft Volume Shadow Copy Service (VSS) "snapshot" technology. CS coordinates VSS-aware components such as applications (Microsoft Exchange Server or Microsoft SQL Server), file-system services, backup applications (Tivoli Storage Manager), storage software, and storage hardware to ensure that the ever-increasing amount of application data is consistent for restore and the application server is recovered. This article is intended for storage architects and administrators who are evaluating the implementation of Copy Services. It explains the concepts used in CS and assumes that a basic understanding of IBM Tivoli Storage Manager and VSS is present.

II. Microsoft VSS

What is VSS?
VSS is a set of Microsoft COM APIs that implement a storage management architecture that enables volume-level snapshots to be performed while the applications that contain data on those volumes remain online and continue to write. This architecture can be used for backing up your applications by creating point-intime snapshots of your data. VSS provides the backup infrastructure as well as the mechanism for creating consistent point-in-time copies of data known as shadow copies. VSS produces consistent shadow copies by coordinating with business applications, file-system services, backup applications, fast-recovery solutions, and storage hardware.

VSS Overview and Terminology Primer

This section provides a brief definition of some of the VSS concepts and terminology used in this document. For example, Figure 1 shows how VSS coordinates with various components to create a shadow copy of a volume.
Figure 1. VSS components

VSS components

VSS Service: This is the Microsoft Windows service that directs all of the VSS components that are required to create the point-in-time snapshot or the shadow copy of the volume(s). This Windows service is the overall coordinator for all VSS operations. Requestor: This is the software application that commands a shadow copy be created of a specified volume. In a Tivoli Storage Manager VSS environment, the Tivoli Storage Manager Backup-Archive Client is the requestor. Writer: This is the software application that places the persistent information for the shadow copy on the specified volume(s). Database applications (such as SQL Server or Exchange Server) or a system service (such as Active Directory) can be a writer. Provider: This is the application that actually produces the shadow copy and also manages their availability. A system provider (such as the one included with the Microsoft Windows operating system), a software provider, or a hardware provider (such as one shipped with a storage system) can be a provider. Shadow copy and volume types Persistent: This is a shadow copy that remains after the backup application completes its operations. This type of shadow copy also survives system reboots.

Non-Persistent: This is a temporary shadow copy that remains only as long as the backup application needs it in order to copy the data to its backup repository. Transportable: This is a shadow copy volume that is accessible from a secondary host so that the backup can be off-loaded. Transportable is a feature of hardware snapshot providers. Source Volume: This is the volume that contains the data to be shadow copied. These volumes contain the application data. Target or Snapshot Volume: This is the volume that retains the shadow copied storage files. It is an exact copy of the source volume at the time of backup. Shadow copy methods Clone (Full Copy/Split Mirror): A clone is a shadow copy volume that is a full copy of the original data as it resides on a volume. The source volume continues to take application changes while the shadow copy volume remains an exact read-only copy of the original data at the pointin-time that it was created. Copy-on-Write (Differential Copy): A copy-on-write shadow copy volume is a differential copy (rather than a full copy) of the original data as it resides on a volume. This method makes a copy of the original data before it is overwritten with new changes. Using the modified blocks and the unchanged blocks in the original volume, a shadow copy can be logically constructed that represents the shadow copy at the point-in-time it was created. Redirect-on-Write (Differential Copy): A redirect-on-write shadow copy volume is a differential copy (rather than a full copy) of the original data as it resides on a volume. This method is quite similar to copy-on-write, without the double write penalty, and it offers storage space and performance efficient snapshots. New writes to the original volume are redirected to another location set aside for snapshot. The advantage of redirecting the write is that only one write takes place, whereas with copy-on-write, two writes occur (one to copy original data onto the storage space, the other to copy changed data).
The VSS Provider implementation determines which type of shadow copy (Clone, Copy-on-Write, or Redirect-on-Write) is created.

Why is VSS important to Microsoft?

Microsoft recognizes that every application (including their multitude of software products) must develop a backup solution. Implementing and maintaining different data protection solutions for each application is costly and problematic. VSS allows Microsoft to provide a storage management infrastructure for applications so that application vendors have a common solution for protecting their application data. A common solution paves the way for eliminating the heterogeneous legacy backup APIs and helps reduce the overall costs of implementation and maintenance.

Why is VSS important to IBM?

IBM recognizes that customers have heterogeneous environments in which the Microsoft platform plays a key role. IBM also recognizes that with increasing amounts of application data and decreasing backup windows, VSS snapshots enable its customers that run their business-critical applications on Microsoft platforms to maintain application availability and still meet their service level agreements.

Why is VSS important to you?

It is important to understand the Microsoft long-term VSS vision and how to prepare to implement it. Since future Microsoft plans might include VSS as the only backup solution for many Microsoft products, it is important to be ready for it. In addition, VSS may be the only solution that enables your enterprise to meet the stringent demands of both application availability and data protection. Back to top

III. How does Tivoli Storage Manager work with VSS?

Tivoli Storage Manager concepts and terminology
This section provides a brief definition of the Tivoli Storage Manager concepts and terminology used in this document. It is assumed that product users have a basic understanding of Tivoli Storage Manager backup and restore strategies in a client/server environment, as well as familiarity with the various components that comprise a Tivoli Storage Manager environment. The following three components comprise a Tivoli Storage Manager VSS requestor environment:

Data Protection Client This Tivoli Storage Manager component provides the user interface from which to enter backup, restore, and query requests, and coordinates with the application server (like Microsoft Exchange Server or Microsoft SQL Server) and other Tivoli Storage Manager components to process these requests. The Data Protection Client makes the decision to facilitate a

VSS backup/restore or to stream the data from the application server directly to the Tivoli Storage Manager server based on the options entered at the command line or GUI. Examples of this component are the Data Protection for Exchange and Data Protection for SQL products. Tivoli Storage Manager Backup-Archive Client This Tivoli Storage Manager component has the VSS Requestor intelligence that facilitates communication to the Volume Shadow Copy Service to perform VSS operations. Specifically, a component called the DSM Agent provides access to the VSS interface functions within Tivoli Storage Manager Backup-Archive Client. The DSM Agent also enables the exploitation of VSS by other Tivoli Storage Manager clients. In the case of Tivoli Storage Manager for Copy Services, it is the Data Protection Client that communicates with the DSM Agent to perform the VSS Backup of the application server. Tivoli Storage Manager for Copy Services This Tivoli Storage Manager component installs the parts required to perform snapshot operations with the Data Protection clients.
There are two important Tivoli Storage Manager product concepts that must be understood in order to comprehend how the software application components interact together.

Proxy Node This is the name given to a Tivoli Storage Manager node (agent) that can act on behalf of another node (target). The proxy node functionality was created to facilitate backup and restore of data to a single namespace by multiple TSM client nodes. In a Tivoli Storage Manager VSS environment, the proxy node function is utilized to enable the Tivoli Storage Manager Backup-Archive Client to act as an agent node on behalf of the Data Protection Client target node. The Tivoli Storage Manager Backup-Archive Client is able to store data under the Data Protection Client node at backup time and restore data stored under the Data Protection Client node at restore time. Client-to-client communication This is the method used for one Tivoli Storage Manager client node to contact and communicate with another Tivoli Storage Manager client node. The nodes can reside on the same or on different computer hosts. The contacting node sends commands to the receiving node to perform backup, query, or restore tasks. The receiving node is always considered a DSM Agent node. Authentication and coordination between these two

nodes is tightly coupled with Tivoli Storage Manager security: the two communicating Tivoli Storage Manager client nodes are in a target-agent relationship as defined on the Tivoli Storage Manager server.
Figure 2. Tivoli Storage Manager VSS environment

Because the Data Protection Client and the DSM Agent are in a proxy relationship, they are able to communicate using client-to-client communication. As a result, during the backup operation, the Data Protection Client communicates with the DSM Agent, which in turns communicates with the Volume Shadow Copy Service. The Volume Shadow Copy Service then communicates with the Application Server (such as Microsoft Exchange Server or Microsoft SQL Server) via the application VSS Writer to start the snapshot. The Data Protection Client supports the following types of VSS Backups:

Local This backup type creates a persistent shadow copy that resides on a snapshot volume. Although this type of backup is managed by Tivoli Storage Manager policy, the actual data resides on volumes local to the VSS Provider and not on Tivoli Storage Manager controlled storage. The VSS Provider software controls how that shadow copy is created and maintained, and the Tivoli Storage Manager policy manages its lifecycle. TSM This backup type creates a copy of application data on Tivoli Storage Manager server storage. This data from an application server VSS Snapshot is copied to the Tivoli Storage Manager server as backup data.

This data is also managed by Tivoli Storage Manager policy. Once this backup is complete, the snapshot volumes are released. Both This backup type creates two copies of application server data. One copy resides on local volumes as a snapshot and another copy (taken from the snapshot copy) is sent to Tivoli Storage Manager server storage. Off-loaded backup: This backup type refers to a TSM backup that is done from a system other than the application server. To accomplish this, a shadow copy volume is imported to a secondary host for the purpose of backing up the application data from the snapshot copy to Tivoli Storage Manager server storage. The benefit is that most of the resource load to back up the files is shifted from the production machine to a secondary host machine. As a result, there is little or no resource impact on the production machine during the VSS Backup. Relating Tivoli Storage Manager backup types with VSS terms
The backup types described previously have a close relationship with the VSS snapshot types in terms of where the data is stored. This section describes how the VSS snapshot types relate to the Tivoli Storage Manager backup types.

TSM This backup type means that the VSS snapshot is non-persistent. The snapshot is created locally and resides locally and exists only long enough to complete the backup to Tivoli Storage Manager server storage. Local When the VSS snapshot data resides locally to the application server, the VSS snapshot is persistent. Both When the VSS snapshot data resides both locally to the VSS Provider and on Tivoli Storage Manager server storage, the VSS snapshot is persistent. Off-loaded backup This backup type means the VSS snapshot is both transportable and non-persistent.
Table 1. Describes these snapshot and backup relationships.

Tivoli Storage VSS Snapshot Manager VSS Backup Type Used Type TSM non-persistent

What Data is Stored on Tivoli Storage Manager Server data and meta data

Where Backup Data can be Located in a Restore Operation Tivoli Storage Manager server storage local snapshot volume Tivoli Storage Manager server storage and local snapshot volume Tivoli Storage Manager server storage

LOCAL BOTH

persistent persistent

meta data only data and meta data

OFFLOAD

non-persistent

data and meta data

VSS restore operations

The Tivoli Storage Manager VSS environment provides the following types of VSS restore methods:

VSS Restore: Restore VSS Backups residing on Tivoli Storage Manager server storage. VSS Fast Restore: Restore VSS Backups residing on local shadow volumes to the correct production volumes using file-level copy mechanisms. VSS Instant Restore: Restore VSS Backups residing on local shadow volumes to the correct production volumes using a volume-level copy mechanism, such as IBM FlashCopy. As of the publication date of this document, VSS Instant Restore is supported on IBM Disk Storage 6000/8000 and SAN Volume Controller.
Back to top

IV. Strategy planning and considerations

Understanding your service level requirements for backup and restore operations
Service level requirements for backup and restore operations are driven by business, administrative, user, and security issues. These requirements directly affect the design of your application server and the backup and restore strategy for the application server data. Consider your business expectations in terms of data availability and recoverability when assessing service level requirements; this is particularly true in regard to the VSS support provided by Microsoft Exchange Server and Microsoft SQL Server. VSS allows you to back up and restore application server data quickly and with minimal impact to the application server clients. This helps to

support larger databases and more users per server. It also helps keep client response times consistent with business needs. You also need to consider your business expectations in terms of uninterrupted operations and planned outages. For example, in the event of a disaster, will the application server need to be restored within one hour or six hours? Will any given database need to be restored within two hours? Answers to these and other questions help you establish a backup and restore strategy. Your backup and restore strategy also determines the types of restore operations you will need to perform. As previously described, the Tivoli Storage Manager VSS environment provides for VSS Restore, VSS Fast Restore, and VSS Instant Restore. The speed of restore for these various VSS restore types can vary greatly depending on the network speed, hardware environment, disk subsystem, and VSS Provider. You may also want to consider what role, if any, legacy backup and restore operations play into your strategy. In some situations, legacy restore methods may provide additional functions and features that are not supported by VSS Restores.

Examining your disk subsystem and hardware environment

To take full advantage of VSS technology with your disk subsystem, work with your hardware vendor to make sure a VSS Hardware Provider that strictly adheres to the Microsoft VSS Hardware Provider specifications is available. In addition, make sure that you follow the disk subsystem vendor VSS Hardware Provider installation and configuration specifications closely as each one has their own prerequisites, configurations steps, and snapshot volume provisioning. You also need to examine the capability of your current disk subsystems for retaining multiple copies of application data snapshots. Snapshots are created in one of three methods: copy-on-write, redirect-on-write, and full-volume copy. The copy-on-write and redirect-on-write methods create a snapshot of a storage volume by using a predesignated space. When the snapshot is first created, only the metadata regarding the original location of the data is copied. As a result, the creation of the snapshot is almost instantaneous. These two methods only track and maintain the changed data blocks from the source volume. This means they completely rely on the original volume in order to perform any type of restore. Full-volume-copy creates a complete copy of the application data from the original source volume to the target volume. This method requires that all data blocks be copied from the source to the target volume but provides less risk than a copy-onwrite because it does not rely on the original volume to restore the data. Note: If your disk subsystem vendor does not have a VSS Hardware Provider, you can still perform some VSS operations by using the Windows System Provider. However, since the Windows System Provider is a software controlled, copy-on-write

technology, there will be performance implications and Tivoli Storage Manager VSS function limitations. For example, if you are using the Windows System Provider, you cannot perform a VSS off-loaded backup or VSS Instant Restore.

Examining the layout of your application data

Since VSS creates snapshots at the volume level, it is recommended that the application data reside on their own volumes. These volumes should not contain any other non-application server data. This will help prevent non-application server data from interfering with the snapshot operations as well as prevent it from being accidentally overwritten when a VSS Instant Restore operation is performed.
Table 2: Example Exchange Server 2003 database and log file layout

It is recommended that you use a naming convention for virtual disks on VSSsupported hardware. A naming convention helps troubleshooting efforts when multiple application servers or other host systems use the same hardware for virtualization. Consider including a VSS disk name as part of each database and log file in all the storage groups.

General strategy considerations

Choose a suitable backup and restore strategy based on your predefined service level requirements. Consider these general factors as they can affect strategy:

Legacy backup versus VSS Backup: Each backup method may provide different types of functions and features. Evaluate the functions and features available with both methods and determine how they might affect service level requirements for your overall backup and restore strategy. VSS Backup to TSM versus VSS Backup to local: Compared to VSS Backup to local, VSS Backup to TSM requires a longer processing time for backup and recovery; however, VSS Backup to TSM stores the data on Tivoli Storage Manager server tape or disk media for long-term retention (e.g. for regulatory requirements). After a VSS Backup to TSM is complete, the target volume is released for use by future snapshots. On the other hand, VSS Backup to local might be a better choice for recovering large databases in a shorter time frame because VSS Fast Restore or VSS Instant Restore can be used. These two restore

methods typically complete much quicker than when restoring a VSS snapshot from Tivoli Storage Manager storage. However, these two restore methods require more target volume space for snapshots. Use Tivoli Storage Manager policy management for the different VSS Backup types. You can assign separate policy management classes for the different VSS Backup destination types and different storage groups or databases. Set these to meet your short-term and long term recovery objectives. Automated (scheduled) backups: You can use the Tivoli Storage Manager scheduler to back up your application data automatically. Define different client schedules for VSS and legacy backups. Make sure backup schedules do not overlap. Tivoli Storage Manager VSS Policy Considerations - Local and Tivoli Storage Manager Server backups
Consider these recommendations when defining VSS policy:

When creating policy for VSS Backups to be stored on local volumes, use the VEREXISTS and VERDELETED management class settings. That is because the number of versions you keep should be based on the numbers of volumes your subsystem has available for shadow copies. The general rule is that if you want to keep N local backups, you need to specify VEREXISTS=N+1. You need to specify N+1 because VSS requires pre-allocated space for taking a snapshot. Many service level agreements base the retention of application server backups stored on the Tivoli Storage Manager server according to specific time periods, not versioning. If that is true in your environment, use the RETEXTRA and RETONLY management class settings instead of VEREXISTS and VERDELETED when setting policy for the backups stored on the Tivoli Storage Manager server. Use different management classes if each storage group has its own retention requirements. Legacy backup management policy remains the same as before. However, adding VSS Backups to your backup strategy might influence you to re-evaluate the frequency and retention of the legacy backups in order to best exploit both legacy and VSS Backup capabilities to meet your service level requirements. Make sure to provision enough local storage on your disk subsystem to meet the management class settings. Tivoli Storage Manager VSS instant restore considerations

VSS Instant Restore is a hardware-assisted, volume level restore which performs a very quick copy of the target volumes back to the original source volumes. This is the quickest restore method in most cases. Consider these recommendations when using VSS Instant Restore:

VSS Instant Restore is not part of the generic VSS infrastructure provided by Microsoft. It requires specialized code to directly communicate with the disk subsystem. As of the publication date of this document, VSS Instant Restore is supported on IBM DS6000, IBM DS8000, and IBM SAN Volume Controller subsystems. Carefully plan the layout of the application data files. A VSS Instant Restore will overwrite all data on the production source volumes. If multiple objects that can be restored individually are placed on a single volume, those objects must be restored as a unit if a VSS Instant Restore is performed. Be aware that Tivoli Storage Manager does provide an option to disable VSS Instant Restore should it be necessary. If you want to preserve any data on the original source volumes, you must manually copy the desired data to a temporary location and replace it after the VSS Instant Restore operation is complete. Tivoli Storage Manager VSS offloaded backup considerations
Setting up your environment for VSS offloaded backups requires the following components:

A secondary machine that has access to the storage area network (SAN). A VSS hardware provider that support transportable shadow copies. The Tivoli Storage Manager nodes are configured in a proxy relationship. For Data Protection for Exchange, a secondary machine that has the Exchange administrator tools must be available. This secondary machine runs the Exchange integrity checker and also moves the data to the Tivoli Storage Manager server. Best practices: General Use the Microsoft VSHADOW or DISKSHADOW utility to validate that the VSS Provider and VSS Writer are configured and working correctly. IBM documents a VSHADOW Prerequisite Test that helps to make sure that persistent, non-persistent, and transportable VSS operations are working correctly in your environment. It is important that the VSHADOW Prerequisite Test is successful BEFORE running Tivoli Storage Manager operations in your environment.

Consider using the VSS backup method exclusively only after you have already successfully tested your VSS backup and restore scenarios and are satisfied with the results. Automate your backup operations by creating different schedules that perform a combination of legacy and VSS Backups to TSM and to LOCAL. However, make sure the backup schedules do not overlap. Use VSS policies to manage the backups to TSM and LOCAL. When performing a VSS backup to LOCAL, it is recommended that a separate management class is set up to always point to a disk storage pool for storing the metadata since the VSS LOCAL backup always remains on local disk. Make sure to provision enough local storage to handle the VSS snapshots defined in your strategy. This step is closely tied to the VSS Provider being used and the size of the volumes containing the application data. See the VSS provider documentation for details on how to provision the storage for VSS operations. When performing VSS operations on devices that perform background copies, make sure that you wait until the background copy completes before attempting a VSS restore operation. Since VSS operations rely on the proper configuration of multiple components, their operations can be problematic. It is important to thoroughly test and retest your backup and restore strategy in a sandbox environment before integrating it into a production environment. Best practices: IBM SAN volume controller Make sure to use the correct hardware, firmware, and hardware provider level on the SVC controller and host system. These components are essential to running VSS operations successfully in an SVC environment. Visit the IBM SVC website to get details on the compatibility matrix. Ensure that enough target volumes are available for creating shadow copy sets. If possible, create a few spare target volumes to guarantee availability at the time that the snapshot is performed. Perform the backup or restore for a single restore entity one at the time. This helps to prevent a timeout failure because multiple background copy processes cannot run simultaneously. In some cases, you might need to manually remove the FlashCopy mappings and consistency groups previously created by VSS utilities or

failed VSS operations. Familiarize yourself on how to do this with the SVC administrator tools. Be aware that VSS Instant Restore brings the application data online in a very short period of time. This means that the application server is operational in a very short period of time as well. However, the background copy of the target volumes (located on the disk subsystem) to the source volumes will continue to run until all of the data is copied. The amount of time this takes is usually based on the size of the volumes and the designated priority of the background copy operation. As a result, any subsequent restore or backup involving those volumes must not be initiated until the current background copy is finished. Best practices: IBM DS6000 and DS8000 series Make sure to use the correct hardware, firmware, and hardware provider level on the DS subsystem and host system. These components are essential to running VSS operations successfully in a DS environment. Visit the IBM DS website to get details on the compatibility matrix. Make sure that enough target volumes are available for creating shadow copy sets. If possible, create a few spare target volumes to guarantee availability at the time that the snapshot is performed. Perform the backup or restore for a single restore entity one at the time. Although both the IBM DS6000 and DS8000 support multiple FlashCopy relationships from a single source volume, a timeout failure can be prevented by not performing concurrent VSS backups and restores. Be aware that VSS Instant Restore brings the application data online in a very short period of time. This means that the application server is operational in a very short period of time as well. However, the background copy of the target volumes (located on the disk subsystem) to the source volumes will continue to run until all of the data is copied. The amount of time this takes is usually based on the size of the volumes and the designated priority of the background copy operation. As a result, any subsequent restore or backup involving those volumes must not be initiated until the current background copy is finished. Best practices: IBM N-series and NetApp Set up the N-series or NetApp VSS Hardware Provider and Internet Small Computer System Interface (iSCSI) or Fibre Channel Protocol (FCP) connections before performing any VSS operations. Tivoli Storage Manager for Copy Services uses the Data ONTAP VSS Hardware

Provider for its VSS support. This provider is a component of N-series or NetApp SnapDrive. It is tightly integrated with the native file system and provides a layer of abstraction between application data and the physical storage associated with that data. Ensure that N-series or NetApp Logical Unit Numbers (LUNs) that are used by the application server contain enough reserved space for snapshots as specified by the number of local backups and the backup frequency in your backup policy. Snapshots created using the N-series or NetApp VSS Hardware Provider are stored on the same volume as the LUN itself. It is recommended that additional space be allocated for planned growth to avoid failure situations. Best practices: Windows VSS system provider Make sure that enough space is available on the source volumes to contain the local VSS snapshots. You can use the Microsoft VSSADMIN utility to provision storage. Only application server data should be placed on the source volumes. Do not put non-application server data on application server volumes. Best practices: Microsoft Cluster Server
VSS is supported in a Microsoft cluster environment. Consider these best practice recommendations when using VSS in the MSCS:

Use basic disks for the application server data files. Use a shared disk to store the Tivoli Storage Manager VSS metadata by setting the VSSALTSTAGINGDIR option in Tivoli Storage Manager client options file before performing any backup operations. If you plan to use VSS Instant Restore in an MSCS environment on Windows Server 2003, you must install Microsoft hotfix 919117. Create and configure identical Tivoli Storage Manager Client schedulers on all of the possible cluster nodes so that the scheduled backups continue even after a cluster failover. VSS LOCAL backups can only be restored from the machine which the snapshots were created on. This is a Microsoft limitation. Performance considerations
There are several performance considerations to evaluate when performing VSS Backups and VSS Restores for large databases:

The amount of overhead involved for VSS snapshots depends on the VSS Provider implementation for the disk subsystem. For example, if the

VSS Provider uses copy-on-write, it may be able to create snapshots almost instantaneously; however, this method relies heavily on the original volumes to restore the data. If the VSS Provider uses full volume copy, it may not require the original volumes to restore data but some operations might take a longer time to complete. During a VSS backup, some application servers might require additional processing that can extend the time required for the VSS Backup to complete. For example, Exchange Server VSS Backups require an integrity check that must scan each page of the database and log files. When performing a VSS Backup to local volumes, there is low overhead since there are no resources needed to send the application data to Tivoli Storage Manager Server storage. In addition, the application server will be in backup mode for a very short period of time. In an Exchange Server VSS environment, consider using the Exchange Local Continuous Replication (LCR) or Cluster Continuous Replication (CCR) features. TSM supports backing up the replica copies of Exchange databases in LCR and CCR environments. This can shift much of the resource strain from the production databases during a VSS backup operation. VSS offloaded backups may provide better overall performance of the production application server machine since the movement of data to Tivoli Storage Manager Server storage is offloaded to the second machine.