Remote Tape Vaulting

Remote tape vaulting allows an IT environment to electronically create backup data at a location that is separate from the primary processing location. By increasing the distance between the production site and tape data required for Disaster Recovery, Business Continuity for the enterprise is enhanced. Additionally, this type of implementation minimizes the risk of tape data being lost or damaged during shipment, and should improve both the Recovery Point Objective (RPO) and Recovery Time Objective (RTO).

A Virtual Tape Library automates tape processing. This allows a VTL to be installed at some distance from the production site without requiring additional staff to support the VTL. The remote location chosen to support the VTL can be the Disaster Recovery facility for the enterprise or another intermediate location. The key selection criteria is that the remote vault must be a "safe" distance from the primary location, and have channel connectivity to both the primary and recovery sites.

A remote tape vaulting configuration can be depicted by a relatively simple diagram, such as the one shown here:

Recovery Specialties, Simple Remote Tape Vaulting example with IBM 3584 and channel extension

In this simple configuration, channels from the production host processor have been extended to a VTL (in this example, an IBM 3584 Virtual Tape Server or VTS) at a remote location. In this diagram, the VTS is located at the recovery site and is connected to the recovery processor via local channels. FICON channels, local to each processor complex, are shown in blue. Channel Extension equipment was used to allow the FICON data to traverse the network.

This type of configuration has been used successfully for several years to achieve Disaster Recovery goals without incurring the additional time and data loss inherent when physically shipping tapes offsite. In fact, this configuration is the critical element that defines a Tier-3 recovery, which by definition can take up to 24 hours to restore critical processing.

However, this type of configuration can introduce processing delays into the production environment. The most noticeable of these constraints is that data written to the remote VTL will take longer than if the data were written locally. This is due to the additional time necessary to write the data over distance.

The Math
750K x 28672	= 21,504,000,000 Bytes
/1024	= 21,000,000 KBytes
/1024	= 20,508 MBytes
/1024	= 20.03 GBytes

For example, suppose that a DB2 image copy when written to a local VTL writes 750,000 blocks of data in just over nine and one-half minutes (9 minutes and 37 seconds to be exact) to successfully copy a tablespace. Further each of those blocks contains 28672 bytes of data with the total amount of data being written being slightly over 20 GBs.

The Math
622 Mb/sec x 0.9	= 559.8 Mb/sec
559.8/8	= 69.975 MB/sec

Now, let us suppose that a remote VTL is connected to the production host with a dedicated OC12 circuit. An OC12 circuit is rated at 622Mb/sec. We must assume that 10% of the rated capacity is absorbed by network overhead, thus approximately 559.8 Mb/sec is available for the tape data transmission. This equals approximately 69.97 MB/sec of data transfer capability.

The Math
20,508 MB/69.975 MB/sec	= 293 sec

The formula for determining the amount of time that will be added to the job when the file is remote vaulted is straight forward assuming that the network resource is unconstrained. Given that the file contains 20,508 MBs of data and the data payload on the circuit is 69.975 MB/sec, then a minimum of 293 seconds (4 Minutes and 53 Seconds) will be added to the job. Of course, this is the minimum amount of time that will be added to the duration of the job. Network constraints effectively reduce the capacity and will cause delays and increase the time required to transmit the file.

However, this slight increase in the execution time of the creating task can easily be justified by the expected benefits to Business Continuity. These benefits can result in the recovery time decreasing from 24-48 hours to something less than a day!

Recovery Specialties, LLC
Enterprise Storage Solutions,
Business Continuity and Disaster Recovery consulting
for z/OS environments

This document was printed from http://recoveryspecialties.com/