Mirroring with Virtual Tape

This page starts of with discussing how mirroring could work with Virtual Tape systems that use physical tapes at the back end, then concludes that the best mirroring solution depends on disk-only VTLs.

The easiest way to mirror data on tape between sites, is to define two sets of tapes drives, with one set working on channel extenders to a remote site. If the cable distance is 12km or less, then you can write to two tapes, one at each location, with very little performance impact. This is illustrated in the diagram below.

Virtual Tape Demonstration

The problem with this approach is that it requires an application which can write to two output files at once. Some backup products (DFHSM, FDRABR) can do this, but few other applications can. This can be fixed by using extra job steps to copy the tapes, but this manual method is error prone. This method also misses out on the benefits of virtual tape.

Both these problems can be fixed, by setting a virtual tape system to duplex its output tapes. The application writes its tape data into a single virtual tape buffer, then the processing within the virtual tape system looks after the duplexing. This is illustrated below

Duplexing the tape out from a VTS

The problem with this is that the application completes before both tape copies are written, so the copy is asynchronous. This might not matter to you, depending on what type of data you are writing to tape and how important that data is. For example if you are creating a deep archive of some project data then you could probably re-create it. On the other hand, if this is the only copy of something really important, then you need to know it is at your remote site, just incase a disaster happens. A more serious problem is that even if the copy tape did get written, without a virtual tape system at your second site, you can't read the tapes.

So the next best answer is to have two virtual tape systems, and mirror the data between the buffers.

Mirroring between VTS systems

This is better, but it is still asynchronous. This is implemented by IBM, in 'deferred copy' mode, and by Oracle VSM in a clustered configuration using immediate migration.

The next level of protection is to hold the application until the data is in both VTS buffers, by holding the tape rewind command

Synchronous VTS mirroring

This is almost there, but it is not quite perfect as the whole file must be written to the source cache before it can be copied to the remote cache. The application has to wait while all the data is written twice and if the file contains a few gigabytes of data, this will take a while. If the job is critical, this delay might not be acceptable. This is implemented by a pair of IBM VTS systems in a PPRC configuration, running in 'immediate copy' mode.

The best way to mirror data, is to do it on a block by block basis. This means that the individual pieces of data are relatively small, and can be transmitted as they are created. This is easiest to do with disk only VTS solutions. As the data is copied block by block, there is a lot of parallelism involved, so even though the applicaton will wait for the tape rewind command and will not get it until the all the data is safely stored in both source and remote cache, this does not take much longer than a single copy.

Virtual Tape Demonstration

back to top

Lascon updTES

I retired 2 years ago, and so I'm out of touch with the latest in the data storage world. The Lascon site has not been updated since July 2021, and probably will not get updated very much again. The site hosting is paid up until early 2023 when it will almost certainly disappear.
Lascon Storage was conceived in 2000, and technology has changed massively over those 22 years. It's been fun, but I guess it's time to call it a day. Thanks to all my readers in that time. I hope you managed to find something useful in there.
All the best