Understanding and exploiting snapshot technology for data protection

Refer to http://www.ibm.com/developerworks/tivoli/library/t-snaptsm1/index.html

                http://www.ibm.com/developerworks/tivoli/library/t-snaptsm2/index.html

Understanding and exploiting snapshot technology for data protection, Part 1: Snapshot technology overview

Helps you make informed decisions about implementing snapshots

Snapshot technology is becoming prevalent to perform data protection and other tasks such as data mining and data cloning. Most leading storage hardware and software vendors provide snapshot support. Advanced data protection solutions like IBM® Tivoli® Storage Manager are being built based on the snapshot technology. Use of snapshot technology for data protection offers critical business value, such as zero impact backup with minimal or no application downtime, frequent backups (for example, hourly) to reduce recovery time, efficient backup of large volumes of data, reduced exposure to data loss, and instant recovery from snapshot. However, you must give careful consideration before selecting a solution that fits your needs and environment.

The goal of this series is to provide an overview of snapshot technology and the snapshot-based data protection solutions offered by IBM Tivoli Storage Manager. This information enables you to make informed decisions about exploiting snapshot capabilities in the most effective way in your environment.

This series is targeted for IT architects, managers, and developers looking for ways to exploit snapshot capabilities to improve quality of the data protection services offered by IT organization.

This part of the series provides an overview of snapshot technology. Refer to the entire series.

View more content in this series | 2 Comments

Neeta Garimella ([e-mail]), TSM Client Developer, Tivoli - Software Group, IBM

26 April 2006

• Table of contents

What is a snapshot

Snapshot is a common industry term denoting the ability to record the state of a storage device at any given moment and preserve that snapshot as a guide for restoring the storage device in the event that it fails. A snapshot primarily creates a point-in-time copy of the data. Typically, snapshot copy is done instantly and made available for use by other applications such as data protection, data analysis and reporting, and data replication applications. The original copy of the data continues to be available to the applications without interruption, while the snapshot copy is used to perform other functions on the data.

Snapshots provide an excellent means of data protection. The trend towards using snapshot technology comes from the benefits that snapshots deliver in addressing many of the issues that businesses face. Snapshots enable better application availability, faster recovery, easier back up management of large volumes of data, reduces exposure to data loss, virtual elimination of backup windows, and lowers total cost of ownership (TCO).

Back to top

How snapshots are implemented

There are different implementation approaches adopted by vendors to create snapshots, each with its own benefits and drawbacks. Therefore, it is important to understand snapshot implementations in order to be able to build effective data protection solutions and identify which functions are most critical for your organization to help select the snapshot vendor accordingly.

This section describes commonly used methodologies for creating the snapshot.

Copy-on-write

A snapshot of a storage volume is created using the pre-designated space for the snapshot. When the snapshot is first created, only the meta-data about where original data is stored is copied. No physical copy of the data is done at the time the snapshot is created. Therefore, the creation of the snapshot is almost instantaneous. The snapshot copy then tracks the changing blocks on the original volume as writes to the original volume are performed. The original data that is being written to is copied into the designated storage pool that is set aside for the snapshot before original data is overwritten, hence the name "copy-on-write".

Before a write is allowed to a block, copy-on-write moves the original data block to the snapshot storage. This keeps the snapshot data consistent with the exact time the snapshot was taken. Read requests to the snapshot volume of the unchanged data blocks are redirected to the original volume, while read requests to data blocks that have been changed are directed to the "copied" blocks in the snapshot. Snapshot contains the meta-data that describes the data blocks that have changed since the snapshot was first created. Note that original data blocks are copied only once into the snapshot storage when the first write request is received.

The following diagram illustrates a snapshot operation that creates a logical copy of the data using copy-on-write method.

Figure 1. Copy-on-write illustration

Copy-on-write snapshot might initially impact performance on the original volume while it exists, because write requests to the original volume must wait while original data is being "copied out" to the snapshot. The read requests to snapshot are satisfied from the original volumes if data being read hasn’t changed. However, this method is highly space efficient, because the storage required to create a snapshot is minimal to hold only the data that is changing. Additionally, the snapshot requires original copy of the data to be valid.

IBM FlashCopy® (NOCOPY), AIX® JFS2 snapshot, IBM TotalStorage® SAN File System snapshot, IBM General Parallel FIle System snapshot, Linux® Logical Volume Manager, and IBM Tivoli Storage Manager Logical Volume Snapshot Agent (LVSA) are all based on copy-on-write.

Redirect-on-write

This method is quite similar to copy-on-write, without the double write penalty, and it offers 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).

However, with redirect-on-write, the original copy contains the point-in-time data, that is, snapshot, and the changed data reside on the snapshot storage. When a snapshot is deleted, the data from the snapshot storage must be reconciled back into the original volume. Furthermore, as multiple snapshots are created, access to the original data, tracking of the data in snapshots and original volume, and reconciliation upon snapshot deletion is further complicated . The snapshot relies on the original copy of the data and the original data set can quickly become fragmented.

IBM N series and the NetApp Filer snapshot implementation is based on redirect-on-write.

Split mirror

Split mirror creates a physical clone of the storage entity, such as the file-system, volume, or LUN for which snapshot is being created, onto another entity of the same kind and the exact same size. The entire contents of the original volume are copied onto a separate volume. Clone copies are highly available, since they are exact duplicates of the original volume that resides on a separate storage space. However, due to the data copy, such snapshots cannot be created instantaneously. Alternatively, a clone can also be made available instantaneously by "splitting" a pre-existing mirror of the volume into two, with the side effect that original volume has one fewer synchronized mirror. This snapshot method requires as much storage space as the original data for each snapshot. This method has the performance overhead of writing synchronously to the mirror copy.

EMC Symmterix and AIX Logical Volume Manager support split mirror. Additionally, any raid system supporting multiple mirrors can be used to create a clone by splitting a mirror.

Log structure file architecture

This solution uses log files to track the writes to the original volume. When data need to be restored or rolled back, transactions from the log files are run in reverse. Each write request to the original volume is logged much like a relational database.

Copy-on-write with background copy (IBM FlashCopy)

Some vendors offer an implementation where a full copy of the snapshot data is created using copy-on-write and a background process that copies data from original location to snapshot storage space. This approach combines the benefits of copy-on-write and split mirror methods as done by IBM FlashCopy and EMC TimeFinder/Clone. It uses copy-on-write to create an instant snapshot and then optionally starts a background copy process to perform block-level copy of the data from the original volume (source volume) to the snapshot storage (target volume) in order to create an additional mirror of the original volume.

When a FlashCopy operation is initiated, a FlashCopy relationship is created between the source volume and target volume. This type of snapshot is called a COPY type of FlashCopy operation.

IBM incremental FlashCopy

Incremental FlashCopy tracks changes made to the source and target volumes when the FlashCopy relationships are established. This allows the capability to refresh a LUN or volume to the source or target's point in time content using only the changed data. The refresh can occur in either direction, and it offers improved flexibility and faster FlashCopy completion times.

This incremental FlashCopy option can be used to efficiently create frequent and faster backups and restore without the penalty of having to copy entire content of the volume .

Continuous data protection

Continuous data protection (CDP), also called continuous backup, refers to backups of data when a change is made to that data by automatically capturing the changes to a separate storage location. CDP effectively creates an electronic journal of complete storage snapshots.

CDP is different from other snapshot implementation method described in this section because it creates one snapshot for every instant in time that data modification occurs as opposed to one point-in-time copy of the data created by other methods.

CDP-based solutions can provide fine restore granularities of objects, such as files, from any point in time to crash consistent images of application data, for example database filer and mailboxes.

Back to top

Snapshot and storage stack

A storage stack is comprised of many hardware and software components that render physical storage media to the applications that run on a host operating system. The diagram below shows commonly used storage stack layers.

Aside from different snapshot implementation methods, snapshot solutions can be implemented in many layers in the storage stack. Broadly, snapshots can be created in software based layers or in hardware based layers. This is also categorized as controller-based (storage device or hardware driven) snapshot or host-based (file-system or volume managers) snapshots.

Controller-based snapshots are managed by storage subsystem hardware vendors and are integrated into disk arrays. These snapshots are done at LUN level (block level) and are independent of the operating system and file systems.

Host-based snapshots are implemented between the device driver and file-system levels. Snapshot can be performed by file systems, volume managers, or third party software. Host based snapshots have no dependency on the underlying storage hardware but depend on the file-system and volume manager software. Also these snapshots operate on the logical view of the data as opposed to the physical layout of the data which is used by the controller-based snapshot.

Figure 2. Storage stack and snapshot

Below are some vendors and products with snapshot solutions at different storage stack layer.

• Storage subsystems: IBM TotalStorage Disk Systems, EMC Symmetrix, NetApp NAS
• Virtualizations: IBM Total Storage SAN Volume Controller
• Volume Managers : Veritas Volume Manager, Linux LVM, IBM Tivoli Storage Manager LVSA, Microsoft® Windows® 2003 VSS System provider
• File systems: AIX JFS2, IBM TotalStorage SAN File System, IBM General Parallel File System, IBM N series, NetApp filers, and Veritas File System

Key observations regarding storage stack:

The storage stack layer in which snapshot is implemented has implications on the data protection solutions. Following are key observations that must be noted.

• Physical storage (provided by storage subsystems) and volume managers, which facilitate use of physical storage, are two essential components in any meaningful storage implementation. These layers are always present.
• Use of file system is optional, as some applications may choose to use the logical volume directly, for example database applications, which cannot be managed by snapshot technologies at the file system layer
• The application layer in the stack may not necessarily provide a snapshot solution, but rather back-up mechanisms tied to the next storage stack layer it interfaces with, that is, file systems or volume managers. This includes quiescing the I/O to allow for a consistent data view.
• Each layer ensures data consistency at its level, hence the buffers in the layers above it need to be flushed out before creating a snapshot.
• File systems and volume manager-based snapshots are typically easy to use and provide better recovery granularity than the hardware-based snapshots.
• Hardware-based snapshots provide protection against hardware failures and better performance. Many implementations offer data consistency groups to ensure consistency across more than one storage unit, such as LUN.

Back to top

Snapshot implementations at a glance

The table below provides a quick look at the various aspects of each of the snapshot implementations described above.

Table 1. Snapshot Implementations Overview at a Glance

 Copy-on-writeRedirect-on-writeSplit mirrorLog structure file architectureCopy-on-write with background copy (IBM FlashCopy)IBM incremental FlashCopyContinuous data protectionSnapshot requires original copy of dataYes: the unchanged data is accessed from the original copyYes: the unchanged data is accessed from the original copyNo: the mirror contains full copy of the dataYes: the unchanged data is accessed from the original copyOnly until background copy is completeOnly until background copy is completeNo-Most implementations include a replica of the original copySpace-efficientYes: in most cases space required only for changed data – exceptions such as IBM FlashCopy exist. Check with the vendorYes:in most cases space required only for changed data. Check with the vendorNo: requires same amount of space as original dataYes: spaces required for the changed dataNo: requires same amount of space as original dataNo: requires same amount of space as original dataYes: space required depends on the amount and frequency of changes to data when multiple point-in-time copies need to be kept.I/O and CPU performance overhead on the system with original copy of the dataHigh: software based snapshot None: hardware-based snapshots (performed by the storage hardware)High: software based snapshot None: hardware-based snapshots (Impact on the storage hardware)Low: after mirror is split High: prior to the split to keep the mirror synchronizedHigh: overhead incurred in logging the writesLow: performed by the storage hardwareLow : performed by the storage hardwareImplementation specific: Check with the vendorWrite overhead on the original copy of the dataHigh: first write to data block results in additional writeNone: writes are directed to new blocksNone: write overhead is incurred before the splitHigh: writes must be loggedHigh: first write to data block results in additional writeHigh: first write to data block results in additional writeHigh: Each write results in a corresponding write to the storage spaceProtection against logical data errorsYes: changes can be rolled back or synched back into the original copyYes: changes can be rolled back or synched back into the original copyYes: data from the mirror must be copied. Typically slower since changes are not tracked.Yes: the changes can be rolled backYes: another FlashCopy can be created in the reverse directionYes: another FlashCopy can be created in the reverse direction. Typically faster, since only the changed blocks are copiedYes: changes can be synched back into the original copyProtection against physical media failures of the original dataNone: valid original copy must existNone: valid original copy must existYes: the split mirror is a full cloneNone: valid original copy must existFull protection after background copy is completeFull protection after background copy is completeImplementation-specific: Check with the vendor

Understanding and exploiting snapshot technology for data protection, Part 2: Protecting data using snapshot and IBM Tivoli Storage Manager

Find out how you can protect data with instant backup and restore capabilities

Snapshot technology is becoming prevalent to perform data protection and other tasks such as data mining and data cloning. Most leading storage hardware and software vendors provide snapshot support. Advanced data protection solutions, such as IBM® Tivoli® Storage Manager, are being built based on the snapshot technology. Use of snapshot technology for data protection offers critical business values such as zero impact back up with minimal or no application down time, frequent back ups (for example, hourly) to reduce recovery time, efficient back up of large volumes of data, reduced exposure to data loss, and instant recovery from snapshot. However, careful considerations must be made before selecting a solution that fits your needs and environment.

The goal of this series is to provide an overview of snapshot technology and the snapshot-based data protection solutions offered by the IBM Tivoli Storage Manager. This information will enable you to make informed decisions about exploiting snapshot capabilities in the most effective way in your environment.

This series is targeted to IT architects, managers, and developers looking for ways to exploit snapshot capabilities to improve quality of the data protection services offered by an IT organization.

This part of the series provides details on building snapshot-based data protection solutions and integrated solutions available in the IBM Tivoli Storage Manager product portfolio. Refer to theentire series.

Implementing snapshot for data protection - Considerations

Snapshots can be used to protect data in more than one way to meet critical business needs.

Using snapshot for traditional backup vs. snapshots as back up

Snapshots can be used to create low-impact traditional backups by creating a consistent point-in-time image of the data being backed up. The backup application uses the snapshot copy of the data, instead of the original copy, to perform backup to a centralized location such as a backup server, reducing minimum interference to the business applications.

Alternatively, frequent snapshots can be created and retained as backups. Such backups are very quick and can be done frequently. These backups allow for fast or instant recovery using snapshot rollback or reverse snapshot or simply by copying the data locally from the snapshot to its original location, which is significantly faster than restoring data from the backup server’s tape storage.

However, snapshot-based backup requires management of snapshot and snapshot storage spaces. As new snapshot- based backups are created, the older snapshots that are no longer required must be deleted and the storage space used by these snapshots must be reclaimed and reused for newer snapshot-based backups. Snapshot interfaces differ by the vendor due to the lack of industry standards in the snapshot management arena, which makes the manual management of snapshots extremely cumbersome to implement and error prone.

Additionally, snapshots should also be integrated with traditional backups to provide one stop recovery solution. An advanced data protection solution such as IBM Tivoli Storage Manager for Advanced Copy Services provides comprehensive policy-driven snapshot management functions.

Why use snapshot for data protection?

Use of snapshots for data protection provides significant business value as described below.

1. Low-impact backups

Traditional backup requires the application be quiesced and remain in read-only state while the backup is in progress in order to ensure data consistency. Snapshot based backup requires application to be quiesced only for the time needed to create the snapshot. This reduces the application’s downtime, minimizing impact on production environment due to backup.

2. Reduced backup windows

Businesses today are constantly challenged to reduce backup windows to meet 24x7 availability requirements. Snapshot technology allows highly effective data protection solutions, such as IBM Tivoli Storage Manager, that require applications be put in backup mode for only the time it takes to create the snapshot. When the snapshot is created, applications can return to their ususal operations. Creating a snapshot usually takes only seconds, thereby reducing the backup window drastically and the application downtime considerably.

3. Off-loaded data transfer

If a snapshot is created using the controller-based snapshot provider, the snapshot could be mounted on an alternate system to perform data transfer to the backup server. This off-loads data movement from the production system, which further reduces impact on the application and reduces the backup window when performing backup to the centralized backup server.

4. Instant recovery

Advanced data protection solutions exploit snapshots to perform data recovery, either by rolling the changes in the snapshot copy back into the primary copy or by creating another snapshot from a previous snapshot, which is retained as backup, on to the primary data storage. This kind of data recovery is done almost instantly, bringing the applications up in a matter of seconds. These advance restore solutions help to improve recovery time objectives (RTO) of an IT organization.

5. Improved recovery points

Since snapshot can be created with low impact to the application, backups can be done more frequently and spread through-out the day, for example every six hours, instead of being a traditional nightly task. Frequent backups reduce the risk of data loss due to missed backup opportunities, which results in significant improvements in recovery point objectives (RPO) of an IT organization.

Note that frequent backups can be taken without having to retain a large number of backup copies as discussed below.

6. Multiple recovery points

Creating a snapshot has low impact to the application. It is possible to keep multiple snapshots, each one representing a point-in-time copy of the data, for instant recovery instead of having only the last snapshot available for quick recovery. This helps to improve the RPO further.

In some cases the most recent backups include the data corruption that is driving the need to restore, so that retaining earlier recovery points protects against situations where data corruption is not immediately detected.

Selecting a snapshot technology provider

When selecting a snapshot technology to implement backup solutions, the following factors need to be considered.

1. Importance of the data

Not all data is created equal. Some data is critical for the business to operate, for example an inventory database for a retail business, whereas others are not as important, such as an historical customer information database used by marketing, services, and data mining applications. Next, identify if a full copy snapshot of the data is required to provide protection against all types of failure or if a copy-on-write snapshot provides an adequate level of data protection against logical data corruption. For example, you can select full-copy snapshot for critical data and copy-on-write for non-critical data.

2. Service level agreements (SLA)

It is important to understand the service level agreements of your IT organization. The recovery point and recovery time objectives stated in the SLA drive the data protection solutions. If recovery time for some data is defined to be under an hour, the solution must support snapshot-based restore or rollback of snapshot to meet those objectives. Recovery point objectives drive the frequency of the backups, which together with the recovery time objective will dictate the number of backups that must be kept at any given time. The required number of backups then help determine the snapshot storage requirements. The estimated cost of this required storage space will also help in selecting the snapshot vendor.

3. Cost - licensing requirements

Some vendors, such as hardware vendors might require separate license purchase for snapshot functions. Whereas snapshot functions implemented in software (file systems, volume managers) can already be part of the base software product and might not require a per-host license. Another important cost factor to consider is the cost of the snapshot storage space, which must be available at the same storage stack layer implementing the snapshot. For hardware-based snapshots, the snapshot LUNs must exist on the same storage subsystem as the primary copy. For a software-based snapshot, it is possible to use cheaper disks for snapshot storage even though primary copy exists on high-end storage systems.

These cost factors must be weighed against the level of protection required for data. Hardware based snapshots provide protection against physical media failures as well logical data corruptions, whereas software-based snapshots protect data only from logical errors.

4. Logical to physical data map layout

The logical to physical data layout becomes an important consideration if you use controller-based snapshots to create snapshots of the file systems or logical volumes. There is a possibility of including more data in the snapshot than is intended if the file system or logical volume in the snapshot is sharing LUNs with other file systems or logical volumes. In such situations, the snapshot itself is usually not a problem except that additional snapshot storage will be required, but the snapshot-based restore results in overwriting the data of all the file systems and logical volumes data sharing the LUNs, which might not be your intention.

Implementing data protection solution using snapshot

Using snapshot to provide application data protection requires in-depth knowledge of the application and snapshot technology. An effective solution coordinates snapshot creation with the application's logic and process flow to provide transactional consistency. There are several steps required to create an effective backup and recovery solution. The IBM Tivoli Storage Manager for Copy Services and Advanced Copy Services modules integrate all of the steps below to provide data protection at the application level.

1. Identify storage unit to snapshot

First, it is important to determine the storage units of which snapshot must be created. The storage unit type depends on the snapshot vendor used to create snapshot. For example, for a file system snapshot the storage unit is a file-system, for volume manager snapshots it is a logical volume, and for a hardware storage subsystem-based snapshot it is LUN. An application can have its data spanning one or more storage units.

It is extremely important to ensure that storage units used by an application are dedicated to the application alone. If this is not true, the impact of taking the snapshot of shared storage units must be assessed. Especially, if the snapshot-based restores are required, because this will restore data on the entire storage unit possibly causing serious data inconsistency issues to other applications that share the storage unit.

For example, a DB2® UDB database uses a file system /customer that resides on LUNs abc-1 and abc-2 that are hosted on IBM Total Storage DS8000, and controller-based snapshot is used to create backups of /customer. If LUNs abc-1 and abc-2 contain data (wholly or partially) from other file systems /usr1 and /usr2, the backup and restore of /customer would result in the backup and restore of the /usr1 and /usr2 file systems in whole or part. This sharing of storage space could result in data inconsistency for file systems /usr1 and /usr2. The same is true if /customer file system contains data that does not belong to the database.

2. Freeze the application

Before a snapshot can be created, the application must be quiesced to ensure consistency of the data. Suspending write activity provides a point-in-time view of the application's state. For example, a DB2 UDB database needs to be in the write suspend mode.

3. Flush cache buffers

The next step is to flush the cache buffers to ensure the application's data is written to the disk. All buffers up to the storage stack layer where snapshot is created need to be flushed. This ensures that the application's point-in-time view of data is indeed the same as what will be in the snapshot. For instance, if the snapshot is performed by the storage subsystem for a DB2 UDB database, which is configured on a file system, all the buffers from the DB2 database, file-system, volume manager, device driver, and disk subsystem are needed to be flushed to complete pending write operations. This can be done by suspending writes on the database, using file-system or operating system provided commands to flush the buffers to the disk.

4. Create the snapshot

Once the application is quiesced and data is in a consistent state at the layer the snapshot is being created, create the snapshot using the vendor specific interface. Storage space for snapshots must be pre-assigned as required by the snapshot vendor.

5. Thaw the application

After snapshot has been created, the application can be made available for normal business operations.

6. Taking the backup

The snapshot created in above step can be used to drive the backup application, which will move data from this snapshot copy to a central backup server. If a snapshot is created using the hardware snapshot provider, the snapshot could be mounted on an alternate system to perform data transfer to the backup server. This off-loads data movement from the production system, reducing impact on the application further.

Alternatively, a snapshot can be retained locally (without moving the data to the backup server) as the snapshot backup for faster recovery. Note: If backup application does not support snapshot management, this snapshot must be managed manually.

7. Releasing the snapshot

Once the backup to the server is complete, snapshot can be deleted to free the resources used by the snapshot or the snapshot can be retained for recovery purposes. If the snapshot is retained, it must be deleted at a later point in time when the backup becomes obsolete to create space for new snapshots.

Back to top

Exploiting snapshot for data protection using IBM Tivoli Storage Manager

As you can see from steps above, snapshot creation and management is complex and cumbersome. Manual management requires extensive knowledge of applications and storage management and is error-prone. This snapshot management task is best accomplished by the data protection solutions that provide snapshot management such as IBM Tivoli Storage Manager.

IBM Tivoli Storage Manager for Advanced Copy Services (supersedes IBM Tivoli Storage for Hardware product set) and IBM Tivoli Storage Manager for Copy Services offer snapshot-based data protection solutions for a number of applications. These products tightly integrate snapshot backups into the regular backup process to provide application integration, snapshot management, integrated view of all available backups, and scheduling and reporting for all types of backups.

IBM Tivoli Continuous Data Protection for Files provides continuous backup for critical corporate data. It runs transparently in background and offers point-in-time based recovery.

The IBM Tivoli Storage Manager Backup/Archive client uses snapshot for functions such as image backup and open file support. Additionally, it provides a generic mechanism to backup a file system from a snapshot copy instead of original copy.

IBM Tivoli Storage Manager for Advanced Copy Services and IBM Tivoli Storage Manager for Copy Services features

IBM Tivoli Storage Manager for Advanced Copy Services and IBM Tivoli Storage Manager for Copy Services components support the following feature set with some exceptions. Please refer to product specific documentation for complete details.

• Zero-impact backups using snapshot
• Instant recovery using snapshot
• Fast recovery using data movement from snapshot copy
• Support for managing multiple backup versions for instant recovery
• Policy-based management of snapshot-based backups
• Single point of control for backup and restore operations
• Off-loaded backups from production hosts to one or more backup hosts
• Integrated management of snapshot and tape backups on the IBM Tivoli Storage Manager server
• Consolidated view of tape and snapshot-based backup

Data protection solutions for applications

This section provides a brief overview of integrated application-specific data protection offerings in the IBM Tivoli Storage Manager suite of products.

1. IBM Tivoli Storage Manager for Copy Services : Microsoft Exchange Volume Shadow Copy Services (VSS) Integration Module 5.3.3

IBM Tivoli Storage Manager for Copy Services for Microsoft® Exchange VSS Integration Module uses Microsoft Volume Shadow Copy Services (VSS) to provide integration between Microsoft Exchange and snapshot providers. IBM Tivoli Storage Manager for Copy Services for MS Exchange VSS Integration Module supports any snapshot vendor that supplies a VSS snapshot provider. This solution allows fast restore as well as instant restore from the snapshots.

IBM Tivoli Storage Manager for Copy Services for Microsoft Exchange VSS Integration Module has been certified with following snapshot providers:

• Hardware providers: IBM San Volume Controller, IBM TotalStorage DS8000, IBM TotalStorage DS6000, IBM TotalStorage N Series filers, and NetApp filers.
• Software providers: Microsoft system providers, which performs snapshot at volume level.

For additional details please refer to the Data Protection for Microsoft Exchange Server Installation and User's Guide.

2. IBM Tivoli Storage Manager for Advanced Copy Services: DB2 UDB Integration Module 5.3.3

The IBM Tivoli Storage Manager for Advanced Copy Services DB2 UDB Integration Module along with the IBM Tivoli Storage Manager for Advanced Copy Services’ Hardware Devices Snapshot Integration Module provides the ability to back up and restore a DB2 UDB database that is partitioned across multiple hosts. This type of multi-partition database consists of multiple logical DB2 UDB database partitions distributed across one or more hosts running on AIX operating systems. Database operations are performed concurrently across all database partitions, thus allowing very large databases to be backed up and restored at a single point in time more efficiently. IBM Tivoli Storage Manager for Advanced Copy Services for DB2 UDB performs a federated backup and restore of a distributed multi-partition database as if it is a single logical database.

IBM Tivoli Storage Manager for Advanced Copy Services - DB2 UDB Integration Module supports following hardware snapshot providers:

• IBM TotalStorage SAN Volume Controller, IBM TotalStorage DS8000, IBM TotalStorage DS6000, IBM Enterprise Storage Server 800.

For additional details, please refer to the IBM Tivoli Storage Manager for Advanced Copy Services for DB2 UDB Installation and User's Guide.

3. IBM Tivoli Storage Manager for Advanced Copy Services: Data Protection for ESS for mySAP 5.3.0 and Data Protection for Disk Storage and SAN VC for mySAP 5.3.1

Data Protection for ESS, Disk Storage, and SAN VC for mySAP features high-efficiency backup and recovery of business-critical databases while virtually eliminating backup-related downtime or user disruption on the production host. It off-loads the transfer of backup data from the database server to an alternate host. The snapshot based restore “FlashCopy Restore” functionality of Data Protection for Disk Storage and SAN VC for mySAP provides a fully automated tool for a fast restore of business-critical databases.

The following hardware snapshot providers are supported:

• IBM TotalStorage SAN Volume Controller, IBM TotalStorage DS8000, IBM TotalStorage DS6000, and IBM Enterprise Storage Server 800.

For additional details, please refer to the Data Protection for FlashCopy Devices for mySAP Installation and User's Guide for Oracle and Data Protection for FlashCopy Devices for mySAP Installation and User's Guide for DB2 UDB.

4. IBM Tivoli Storage Manager for Advanced Copy Services: Data Protection for ESS for Oracle 5.2.2 and Data Protection for Disk Storage and SAN VC for Oracle 5.3.1

Data Protection for ESS, Disk Storage, and SAN VC for Oracle features high-efficiency backup and recovery of business-critical databases while virtually eliminating backup-related downtime or user disruptions on the production database server.

Data Protection for Oracle off-loads the transfer of backup data from a production database server to a backup database server. The snapshot-based restore “FlashCopy Restore” functionality of Data Protection for Disk Storage and SAN VC for Oracle provides a fully automated tool for a fast restore of business-critical databases.

The following hardware snapshot providers are supported:

• IBM TotalStorage SAN Volume Controller, IBM TotalStorage DS8000, IBM TotalStorage DS6000, and IBM Enterprise Storage Server 800.

For additional details, please refer to the Data Protection for FlashCopy Devices for Oracle Installation and User's Guide and Data Protection for Enterprise Storage Server Databases (Oracle) Installation and User's Guide.

IBM Tivoli Continuous Data Protection for Files

IBM Tivoli Continuous Data Protection for Files provides round the clock data protection to file data on Windows. It allows as many as three target backup/replication areas for high-priority files: a local disk, a file server or Network Attached Storage (NAS) appliance, and an IBM Tivoli Storage Manager server. The backups to IBM Tivoli Storage Manager server can be scheduled as well to provide integration tape vaulting of corporate data.

IBM Tivoli Continuous Data Protection for Files offers point-in-time or version-based recovery options. Files are versioned using the date and time for easy identification.

For additional details, please refer to the product manual IBM Tivoli Continuous Data Protection for Files.

Data protection using IBM Tivoli Storage Manager Backup-Archive Client

IBM Tivoli Storage Manager Backup/Archive client uses software-based snapshot providers that are platform-specific to support image backup, open file support and system-state backup on the Windows platform that include the following.

1. Snapshot support for Microsoft Windows platforms

IBM Tivoli Storage Manager Backup/Archive client uses Logical Volume Snapshot Agent (LVSA), a volume level snapshot provider that is available with IBM Tivoli Storage Manager to support open file support and online image backup. LVSA creates a snapshot of the volume being backed up and uses the snapshot copy to create a backup on the IBM Tivoli Storage Manager server. This frees the original volume to allow applications to continue while backup to IBM Tivoli Storage Manager Server continues. LVSA uses the copy-on-write implementation to create snapshot.

Windows® system state backup uses the Microsoft Virtual Shadow Copy Service to perform backup of system state files.

Refer to the IBM Tivoli Storage Manager for Windows - Backup-Archive Client Installation and User's Guide.

2. Snapshot support for Linux platforms

IBM Tivoli Storage Manager Backup/Archive client uses the Linux® Logical Volume Manager snapshot to provide online image backup. It creates a snapshot of the volume being backed up and uses that snapshot copy to create a image backup on the IBM Tivoli Storage Manager server, thus making the original volume available to applications while backup continues. The Logical Volume Manager snapshot uses copy-on-write implementation to create snapshots.

Refer to the IBM Tivoli Storage Manager for UNIX - Backup-Archive Client Installation and User's Guide.

3. Generic snapshot-based backup support

IBM Tivoli Storage Manager Backup/Archive features a generic method of integrating with any snapshot vendor via the “snapshotroot” option to perform file level backups to IBM Tivoli Storage Manager Server. This option allows a file-system to be backed up from the location where the snapshot is mounted, while preserving the original file system name as the file space on the Tivoli Storage Manager Server. The entire backup operation is performed using the snapshot copy, leaving the original file system to the application.

The snapshot of the file system must be created using the vendor-specific interfaces, IBM Tivoli Storage Manager B/A client can then be told to backup the file system from the location where snapshot is made available using snapshotroot option. You no longer need to maintain the snapshot when the backup completes. TSM provides the capability to run scripts at the start and end of a schedule, which can be used to manage the creation and cleanup of snapshots. In order to ensure data consistency at the application level be sure to quiesce the application before taking the snapshot and flushing all the buffers in the storage stack layers as explained earlier.

Off-loaded backup support is not available using IBM Tivoli Storage Manager backup/archive client. However, it can be accomplished by creating a controller-based snapshot, mounting it on an alternate host and using the snapshotroot option to perform the backup.

Refer to the IBM Tivoli Storage Manager’s platform specific - Backup-Archive Client Installation and User's Guide.

Back to top

Conclusion

Snapshot technology promises to move data protection services into the next generation by facilitating instant backup and instant restore with no or minimal impact on applications due to data protection needs. Snapshot technology is offered at almost every storage stack layer by increasingly large number of vendors. When implementing snapshot-based data protection solutions, you must consider and understand all implications. IBM Tivoli Storage manager provides comprehensive solutions that offer a rich set of functions to meet challenges in protecting data in today’s business environment that demands zero down-time.