SSI Recommendations: CA VM:Backup 

08-04-2014 10:58 AM

How have you implemented CA VM:Backup in an SSI environment? Below you will find a draft of our recommendations. Do they differ from your experience? Do you have any best practices? Is the information below helpful and adequate?

Feel free to edit this document, adding information that you think could be of use to other customers. Please collaborate with us on creating a set of recommendations.

In an SSI environment, most DASD volumes are globally shared among all members of the complex while certain other volumes are private to each member system.  Most virtual machines are able to log on once in the complex on any member, while others will be able to log on multiple times, once per member system in the complex. In order for normal user virtual machines to be able to log on to any member of the complex, minidisks must be allocated on globally shared DASD.  Similarly, virtual machines that can log on to more than one member simultaneously should have minidisks that are allocated on private volumes.


It is critical when creating and manipulating directory entries, that you follow this convention:

  • Minidisks for normal users must be allocated only on globally shared volumes
  • Minidisks defined for IDENTITY virtual machines in a SUBCONFIG be allocated only on volumes that are private to the member on which the SUBCONFIG is built.

Failure to follow this convention may prevent successful backups.


CA VM:Backup can be used in an SSI environment as follows:

  • Multiple CA VM:Backup servers must be deployed as normal user IDs.  One of these servers (probably VMBACKUP) will be responsible for backing up and restoring normal VM user IDs having minidisks that are allocated on shared DASD.  This user ID (VMBACKUP) can be run on any member because it works with DASD volumes that are globally shared.
  • VMBACKUP must be prevented from backing up private volumes.  This is done by setting up an exclusion file that excludes all of the private DASD volumes as well as user IDs you do not want to backup at all (for example, $ALLOC$).  You can do this with the 'Manage Exception/Exclusion Files' screen, which is accessible from the System Administrator Main Menu. This screen allows you to work with a maximum of 12 volsers. If you have more private volumes containing minidisks, you will have to import a TPI exclusion file.  In either case, be sure to specify the Exclude DASD volumes and one or more Excluded user IDs.
  • The other CA VM:Backup servers (probably named VMBKUP01 through VMBKUP04) will be responsible for backing up minidisks that are defined on private volumes specific to each member. These servers must be run on the specific member that has access to the private DASD to be backed up.  You are responsible for ensuring these user IDs will be logged on to the correct member.  To ensure these servers back up only private DASD volumes, you must specify the private volsers in the Include DASD fields of the backup template.


Because we are deploying normal servers with unique user IDs, you will be able to control these servers using the VMBACKUP,VMBKUP01, VMBKUP02, VMBKUP03 and VMBKUP04 command modules produced during deployment of the servers.  These programs should reside on globally shared minidisks.


In order to issue a VM:Backup command from an IDENTITY virtual machine when the server is on a different SSI member, you must include a DISTRIBUTE IUCV TOLERATE statement in the shared SYSTEM CONFIG file.  Because IBM requires the same DISTRIBUTE settings for every member of an SSI complex, you must make the change in the SYSTEM CONFIG file, SHUTDOWN every member, and then re-IPL every member for the change to take effect.  You cannot change the DISTRIBUTE setting and then SHUTDOWN and IPL each member one at a time.

0 Favorited
0 Files

Tags and Keywords


08-20-2014 02:22 PM

Exactly. The user shouldn't have to care. Not their problem.


The catalog functions and job definition/master job database are the key functions that are shared between nodes, and those are reasonably portable between nodes. The satellite pieces that do the actual backup work need access to that information at the start of a job, but could defer reporting until the end of the job via a IUCV connection to the VMBACKUP server.

08-15-2014 10:01 AM

Here is my Opinion: VMBACKUP is a tool that is also used by the users as well as System Administrators. It may not be to bad for the Administrators to understand that there are 5 VMBACKUP machines all with different names, but users are another story. In a perfect world all users will be Identities and have all their disks on Common Shared volumes that are backed up by the VMBACKUP SVM. In this situation the user only interfaces with one VMBACKUP service machine. In what I would see as a more realistic world there will be a mix of users that are IDENTITY entries that have both Common and Private minidisks much like one of your own defined SVM VMSECURE. A common Shared VMBACKUP Catalog disk would allow all disk to be restored from a single user interface (VMBACKUP) where common disks would be restored on the local system and Private disks would have requests sent to the appropriate VMACKUP agent on the appropriate system. Maybe that would be the perfect world and a pipe dream.


My Honest dream world would be for a VMBACKUP interface that completely manages the backup of all data utilizing agents on each system, Like the VMSECURE servant facility and restore requests would be through the same VMBACKUP interface and the catalog would tell how and/or where the restore process needs to run.

08-14-2014 01:04 PM

I was told this ought to be more an "idea" so I added it there.

08-14-2014 11:47 AM

What is the problem(s) with the current implementation that you feel would be addressed with the suggested implementation of making VM:Backup work like VM:Secure?  Let us know all of the things that you don't like with the current recommendation for set up or what that set up prevents you from achieving.

08-13-2014 11:55 AM

We have VMBACKUP set up this way. VMBACKUP backs up globally mounted disks, VMBKLOCx runs on each LPAR to back up disks that are mounted only on that LPAR. What would be nice? If VMBACKUP worked like VMSECURE and I could have VMBACKUP on all LPARs, let the master assign work to the appropriate LPAR when the master can't get to a resource. No small matter I know, but a wish none the less.

Related Entries and Links

No Related Resource entered.