Page 1 of 8

V5R4 Virtual Tape on System i By Nancy Roper, IBM Americas Advanced Technical Support – System i

Article Abstract : "Virtual Tape was introduced to i5/OS starting at V5R4. Read on to

learn about the features and benefits of this function, along with hints and tips to use it to

your advantage"

About the Author: Nancy Roper is a Consulting IT Specialist. She currently works in the

IBM Americas Advanced Technical Support group, assisting the largest System i

customers with their availability strategies. Nancy is a seasoned technical expert on

System i tape, SAN, and BRMS, and is co-author of the redbook “iSeries in a Storage

Area Network” (SG24-6220).

As the pace of the world quickens, more and more companies need to keep their systems available

for as many hours as possible each day. Since backups typically account for a major portion of the

time that a system is not available, companies are very interested in tools and techniques to shorten

the backup window as much as possible.

At V5R4, a new function became available in i5/OS to assist in this task. Virtual Tape allows cus-

tomers to write their saves to virtual volumes that are stored on disk, and later duplicate these vol-

umes to physical tapes. For saves with large file data, and for companies who are using older tape

technology, this may offer a dramatic performance improvement, thus shortening the time when the

system is unavailable to the users. In addition, concurrent or parallel saves can be implemented us-

ing virtual tape, thus shortening the backup window without needing to purchase additional physical

drives.

If this function seems interesting to you, then read on! This article will explain how virtual tape

works, and describe the scenarios where this function can be helpful. It will also warn of situations

where virtual tape may not be the best fit. This article will then outline the planning steps required to

prepare for virtual tape, and list the steps required to implement it.

Benefits offered by Virtual Tape

Virtual tape provides the following potential benefits:

- Possible Backup Performance Increase

- Run Concurrent or Parallel Backups, without buying more drives

- Overcome Save File Restrictions

- Reduce Impact of Media Errors

- Reduce Impact of Tape Hardware Failures

- Backup Strategy for Quick Restores

Details regarding these advantages are as follow:

Possible Backup Performance Increase: Virtual tape saves typically run at speeds comparable to

save files when they are on a system with adequate resources. Depending on the type of physical

drive currently in use, this may provide a performance benefit, thus helping to shorten the backup

Page 2 of 8

window. For details, see the benchmarks in the Save/Restore chapter of the V5R4 Performance Ca-

pabilities Guide, which is available on the web at the following url:

http://www-03.ibm.com/servers/eserver/iseries/perfmgmt/resource.html

Run Concurrent or Parallel Backups, without buying more drives: One technique for reducing

the backup window is to run multiple drives simultaneously using concurrent or parallel backups.

With virtual tape, this can often be done without purchasing additional tape devices. i5/OS allows

up to 35 virtual tape devices to be varied on simultaneously. The saves can be sent to virtual de-

vices, and once complete, the users can return to their work. The virtual volumes can then be dupli-

cated to physical tapes as drives become available.

Overcome Save File Restrictions: Save files have been used for many years on the System i in or-

der to send saves to disk first, and later save them to tape. They offered good speed, but they had

several restrictions that are no longer an issue with virtual tape:

One Library per Save File: When using save files, a separate save file was needed for each li-

brary that was saved. For customers using Backup, Recovery and Media Services (BRMS), this

was not an issue because BRMS created the save files in the background. However, for custom-

ers who used native commands, the save files needed to be created and managed manually.

With virtual tape, an entire system save can be sent to a single virtual volume, thus avoiding this

situation.

Save-While-Active across Libraries: With save files, each library had to be saved with a separate

command in order for it to reside in a separate save file. This meant that save-while-active syn-

chronization could not span libraries when using save files. With virtual tape, multiple libraries

can be saved on a single command, thus allowing save-while-active checkpoints across libraries

Parallel Saves: Parallel saves could not be stored in save files. However, they CAN be saved to

virtual volumes. Note that the number of virtual drives should match the number of physical

drives that will be used for the duplication when parallel saves are used. This is required so the

parallel save “media definition” written to the tapes will be correct.

SAVSYS: SAVSYS system saves cannot be sent to save files. However, they CAN be sent to

virtual volumes. Note that the virtual volume needs to be duplicated to physical tape before it

can be used to perform a system recovery (D-IPL). The system cannot be IPL’d from a virtual

volume that is still stored on disk.

Larger Libraries can be saved: Save files had a maximum size of 1 TB. In order to save a bigger

library to save file, it had to be carved into multiple object saves. With virtual tape, this restric-

tion is removed.

Reduce Impact of Media Errors: As a customer’s tape inventory ages, they may begin to see occa-

sional media errors. These typically cause the saves to fail. It’s often difficult to get the saves re-

issued and completed within the maintenance window, particularly save-while-active saves that

would need to be restarted from the beginning in order to create the checkpoint again. Virtual tape

Page 3 of 8

uses disk as the underlying media which is typically protected from errors via RAID or mirroring

protection, so media errors are less likely to affect the backup. Errors that occur during duplication of

virtual media do not impact the production application, so are typically less of a concern.

Reduce Impact of Tape Hardware failures: With physical drives, the nightly backup window

would be affected if a drive was ever broken or unavailable. However with virtual tape, the backups

can still be run to virtual volumes as scheduled. The duplication to physical media can be delayed

until another physical drive is available.

Backup Strategy for Quick Restores: Some companies may devise a backup strategy whereby they

keep the virtual volumes on disk even after duplication. The physical tapes are moved to offsite stor-

age in case of a system or site loss. Meanwhile, adhoc restores can be performed quickly from the

virtual volumes. A similar strategy was available with save files, although it was cumbersome for

non-BRMS customers due to management of multiple generations of save files.

Scenarios where Virtual Tape may not be a Fit

There are some situations where virtual tape may not be the best choice of tools for a given backup

strategy. Two examples are as follow:

Misconception re Zero Downtime: There is a misconception that Virtual Tape somehow magically

allows backups to run with no downtime. This is not true. Virtual Tape provides very fast backup

speeds for customers with large file saves. Think of it as a very fast tape device. It would need to be

combined with other techniques such as save-while-active, external disk point-in-time-copy, or high

availability business partner solutions in order to shrink the backup outage to a small or negligible

timeframe.

Scenarios where Virtual Saves Don’t Offer any Performance Advantage: Sometimes virtual tape

will not provide any performance advantage. For example, consider a company that is currently us-

ing the latest tape device technology and has data that falls in the “user mix” category. The bench-

marks suggest that both their tape saves and their virtual tape saves will run in the 200-220 GB/hr

range. That means that the outage for the users would be approximately the same regardless of

which technology was used. However, with virtual tape, there would be an extra step to duplicate

the data to physical tapes afterwards. This would possibly put extra load on the system depending

how the disk was configured, and would also broaden the window of exposure when the data was not

yet safely on tape. Meanwhile, extra costs would have been incurred to buy the extra disk to hold the

virtual volumes. In this case, virtual tape may not have been the best choice, unless the company

was interested in some of the other benefits of virtual tape, eg multi-streaming of saves, avoiding

media errors, etc.

Technical Details regarding Virtual Tape

As mentioned above, i5/OS V5R4 introduced a software based virtual tape solution. It is included in

the operating system at no extra charge. It provides similar function to the hardware-based virtual

tape solutions that are offered on other platforms.

Page 4 of 8

Virtual tape is supported on every i5/OS save/restore command and API on System i, except for

SAVSTG.

There are a couple of places where virtual tape cannot be used:

• It cannot be used for installing i5/OS or Licensed Internal Code (LIC): these need to be in-

stalled via CD or from a physical tape containing a SAVSYS save.

• It cannot be used for tape operations initiated from System Service Tools (SST) or Dedicated

Service Tools (DST), such as a main storage dump or a dump to media: these need to run di-

rectly to a physical tape.

Virtual tape is compatible with all tape devices that are currently supported by i5/OS. When virtual

volumes are created, the density needs to be chosen to limit the block size to those acceptable for the

physical tape devices that the save will be duplicated to. The maximum block size allowed for a vir-

tual volume can be changed at any time by re-initializing the volume to a different density. Data

saved to a volume with density *VRT32K is compatible with all drives, but larger block sizes will

provide better performance, so companies are encouraged to use the largest block size supported on

their physical drives. The Virtual Tape redbook has an appendix showing the highest supported den-

sity and block size for each Tape device.

Virtual volumes are created as Integrated File System (IFS) stream files. They can be placed in the

system Auxiliary Storage Pool (ASP), in a user ASP, or in an independent ASP (IASP). User ASPs

and IASPs are highly recommended in order to avoid disk contention which could cause perform-

ance degradation. Disk i/o’s used for save/restore typically have a much larger block size than regu-

lar i/o’s, so when they are intermixed in one ASP, the production i/o’s may have to wait behind the

longer save/restore i/o’s, thus impacting performance on the production application.

Virtual volumes can range in size from 48 MB to 1 TB in size. There is great flexibility when dupli-

cating the virtual volumes to tape. If the virtual volumes are smaller than the physical tape, then

multiple volumes in the virtual set will be accumulated on the physical tape. If the opposite is true,

ie the virtual volume is bigger than the physical tape that it is being duplicated to, then the save can

roll to new physical volumes as needed.

When virtual volumes are created, the user has the option of asking to have the full amount of disk

space allocated and formatted up front, or having a tiny 4K space allocated, that will then be ex-

panded as the save is written. Save performance is considerably better if the space is pre-allocated,

but companies who want to minimize the disk space used by scratch volumes may choose to use the

smaller initial allocation. There is a command (WRKIMGCLGE, then select option 12 to Work with

Entries, then use option 2 to change the desired virtual volume) that will trim the virtual volume

down to the size of the data that is stored on it. This could be used if the user changed his mind after

pre-formatting all the virtual volumes, or if a tape expired, and a second smaller save was written to

it, so there was excess space formatted that could be released.

Virtual tape is implemented using the same techniques as virtual optical. An Image Catalog is cre-

ated which specifies the IFS directory where the virtual volumes will be created. People find it help-

ful to think of the Image Catalog as the virtual tape equivalent of the cartridge magazine on a 3590 or

Page 5 of 8

3570 or TS3100 (3581) Tape device, with a set of numbered slots. The virtual tape Image Catalog is

a giant cartridge magazine that can hold up to 256 virtual volumes. When a virtual tape operation

needs to run, the image catalog is mounted onto one of the virtual drives, and then the tapes inside it

are used for the tape function. Multiple Image Catalogs will be required if multiple virtual drives

will run simultaneously. When using BRMS, the image catalogs are mounted automatically, but

when running virtual tape via i5/OS commands, the user needs to mount the image catalog.

When issuing a save command, there are two parameters, compression and compaction, that may

need clarification. “Compression” indicates compression done at the system side. It was important

in the early days when staff was typically not available overnight to mount tapes, so maximizing the

data on each tape was important, even at the expense of performance. It is typically not used on cur-

rent tape devices due to the performance impact. “Compaction” indicates compression that is done

at the drive side. It is typically used on current tape devices and typically gives a 3:1 compaction ra-

tio, and corresponding performance increase on traditional System i libraries since 3 times as much

data is going to tape in each write. For virtual tape, compression is available, but not recommended

because it only uses low compression (approximately 1.5:1) and has a high performance overhead.

Compaction is not available when saving from disk to virtual volumes. However, when virtual vol-

umes are duplicated to physical tapes, compaction can be used to gain the usual benefits. Note that it

needs to be explicitly requested on the DUPTAP command via compaction *YES, not via compac-

tion *FROMFILE.

BRMS and Virtual Tape

Virtual Tape is supported by BRMS for most functions. Using BRMS is recommended since it helps

to keep track of the virtual volumes and their duplicates, and helps to manage the expiry and re-use

of the virtual media. In addition, BRMS automates some of the functions related to mounting image

catalogs.

Planning for Virtual Tape

Prior to implementing virtual tape, some planning is required. Here are the basic steps:

• ASPs for Virtual Volumes: Decide where to store the virtual volumes: the system ASP, a

user ASP, a standalone IASP, or a switchable IASP

• Disk Space: Decide how much new disk will be required to hold the virtual volumes. This

will depend on what data will be saved and whether it will be kept on disk for adhoc restores

after the duplicate tapes are made. Remember to include space for scratch virtual volumes

and recall that the data is not compressed when it is sent to virtual volumes. Allow a small

amount of extra disk (1-3%) for the various save information associated with the virtual vol-

umes.

• Virtual Volume Sizes: Decide what sizes of virtual volumes to create. Smaller volumes pro-

vide more flexibility since small saves can be written on a single tape, or larger saves can

span multiple tapes. One idea might be to make a series of smaller virtual volumes in one

Page 6 of 8

image catalog for smaller saves, and a series of larger volumes in another image catalog for

full saves. In BRMS these could be treated as different media classes as though they were

long/short tapes in the 3590 and 3592 world.

• Virtual Devices and Image Catalogs: Decide how many virtual drives and image catalogs

will be required, depending on the backup strategy.

• Performance: Consider the resources that will be required on the system to drive the virtual

saves: CPU capacity, memory, and disk arms. The Performance Capabilities Guide men-

tioned earlier in this article has some virtual tape benchmarks that may help. The CPU,

memory and disk arm benchmarks for physical tape devices may also be useful to provide a

starting range. Additional testing and benchmarking may be required as the virtual tape pro-

ject progresses.

• Saving the Virtual Volumes: decide whether to save the virtual volumes that are on disk

during a regular save of the system. If the IFS directory that contains the virtual volumes is

saved while the image catalog is in “ready” status, then the virtual volumes in that image

catalog are not saved. If the image catalog is in “not ready” status, then the virtual volumes

in it are saved. This could increase the save time dramatically. If desired, there are several

ways to control whether the virtual volumes on disk are saved when their directory is saved:

• Use the CHGATR command on the IFS directory where the virtual volumes are

stored, and mark them as “do not save”

• Use the LODIMGCLG command to mount the image catalog prior to running the

save, so the virtual volumes will be omitted

• When using the SAV command or BRMS equivalents, use the OMIT parameter to

specifically omit the directories that have the virtual volumes in them

Implementing Virtual Tape

In order to implement virtual tape, the following steps are required for both BRMS and non-BRMS

users:

• Install New Hardware: Purchase and install any new hardware required for the project, eg

CPU, memory, or disk

• Create any ASPs or IASPs required: Do the appropriate planning and setup for any new

user ASPs or IASPs that will be required.

• Create the Virtual Devices: this command needs to be done using the i5/OS CRTDEVTAP

command. It is not available via the iSeries Navigator panels.

• Create the Image Catalogs: this command can be done via the ISeries Navigator or via the

i5/OS CRTIMGCLG command.

Page 7 of 8

• Create the Virtual Volumes: this command can be done via the ISeries Navigator or via the

i5/OS ADDIMGCLGE command.

• Run a Test Virtual Save without BRMS: Vary on the virtual device. Load the image cata-

log into the virtual device using the LODIMGCLG command. Check the volumes in the im-

age catalog using the WRKIMGCLGE command and record the volume serial number of the

one to be used for the test save. Issue the SAVLIB command, indicating the virtual tape de-

vice and the virtual volume serial number. If desired, use DSPTAP to view the data on the

tape. Note that all of these commands can also be done using ISeries Navigator.

• Duplicate the Tape to Physical Media without BRMS: Use the DUPTAP command to

copy the virtual volume to a physical tape on the desired drive. Recall that the block size

must be compatible between the virtual volume and the physical tape. Remember to set the

Compaction parameter to *YES if compaction is desired at the drive.

For users who will be using BRMS, the following additional steps are required:

• Initialize the BRMS Devices: Use INZBRM OPTION(*DEVICE) to set up the BRMS De-

vice Descriptions for the virtual drives and the 4 default Media Classes, namely VRT32K,

VRT64K, VRT240K, and VRT256K.

• Create BRMS Locations: Create BRMS locations for the virtual volumes. It is usually help-

ful to have separate locations for virtual tapes and physical tapes. Some companies also

make a separate location for virtual tapes that have already been duplicated but are still avail-

able on the system, in order to keep these tapes separate from those awaiting duplication.

• Update the BRMS Device Descriptions: Update the BRMS Device Descriptions for the vir-

tual drives to use the locations created, and also set the other parameters required for your

backup strategy.

• Create BRMS Media Classes: Create any additional BRMS Media Classes required. Note

that the media classes to be marked as non-shared.

• Create BRMS Move Policies: Create any new BRMS Move Policies required, or update ex-

isting ones. If a separate location is being used to indicate virtual tapes that have already

been copied, then a move policy will be required to move the virtual tapes to that location,

and return them when they expire. A move policy will also likely be needed to send the du-

plicated physical tapes offsite.

• Create BRMS Media Policies: Create any new BRMS Media Policies required, or update

existing ones. The “Mark Tapes for Duplication” field is helpful for automating the process

of duplicating the virtual volumes to physical tapes.

• Create BRMS Control Groups: Create any new BRMS Control Groups required, or update

existing ones

Page 8 of 8

• Set up DUPMEDBRM Commands: Add any additional DUPMEDBRM commands to the

daily job streams to duplicate the virtual volumes to physical tapes. Confirm that the media

information is being saved following the duplication either via the DUPMEDBRM

SAVMEDINF parameter, or via the SAVMEDIBRM command

• Set Up Daily BRMS Maintenance: Review the STRMNTBRM and/or STREXPBRM com-

mands in the daily maintenance jobs to confirm they will clean up virtual tape media as de-

sired

• Test and Implement: Test the new backup strategy carefully, then add the new virtual tape

backups to the daily job streams

As always, once the new backup strategy is designed, plans should be made to run a recovery test to

ensure the strategy is sound, and staff are comfortable with the recovery procedures.

Summary

Virtual Tape provides new options for companies who are interested in shortening their backup win-

dow. It can provide faster backups due to improved performance and the ability to run concurrent

and parallel saves without purchasing extra physical tape devices. It can also reduce the impact of

media errors during the saves, or hardware problems on the physical tape devices. In addition, new

strategies can be devised where virtual volumes are used for adhoc onsite restores rather than recall-

ing duplicate tapes from offsite. Be sure to plan the implementation in advance, particularly the

hardware resources required for good performance. Use BRMS in order to manage the implementa-

tion well. Be sure to test the backup carefully prior to implementation, and plan a recovery test to

ensure the system can be recovered smoothly.

For more detailed information about the virtual tape function and step by step instructions to imple-

ment it, please see the redbook entitled “i5/OS V5R4 Virtual Tape” which is available at

www.redbooks.ibm.com. The publication number is SG24-7164.

Many thanks to Debbie Saugen, Joe Kochan, Christian Aasland, and David Bhaskaran for their assis-

tance in writing this article.