Backup overview


For recoverability of data, you must take periodic backups of files. A backup is simply a copy of the data. If the original file is lost or damaged, if the data is corrupted by a logic error, or if you need a duplicate copy of the file for testing, the file can be restored to its original condition by using the backup data set. For complete information about how backups are used during restore processing, see Restoring-VSAM-data-sets.

As explained in this section, RUV automates and optimizes the handling of backups. The following sections provide overview information about these topics:

  • Backup methods that RUV supports
  • Strategies that you can use to manage backups
  • Backup registration records in the repository
  • Considerations for backups
Warning

Note

For information about how to produce backups of the RUV repository, see Maintaining-the-RUV-repository.

This topic contains the following information:

Backup methods

RUV supports a wide variety of backup methods.

Warning

Note

When RUV automatically selects a backup to restore, it selects the backup that is the most current (the latest backup that has occurred before the target recovery time).

RUV backups

You can use the RUV Backup function to create one or more copies of KSDS, ESDS, RRDS, VRRDS VSAM base clusters, and sequential files. RUV writes these RUV backups as sequential data sets on tape or DASD.

RUV automatically detects and restores RUV backups during restore and forward recovery processes. During a VSAM sphere backup, RUV can record enough information to allow it to automatically delete/define the file and rebuild any alternate indexes during a restore.

For more information, see Creating-RUV-backups.

VSAM BWO backups

If your CICS regions need constant access to your VSAM files, you can use the Backup-While-Open (BWO) feature of RUV to take BWO backups (also known as fuzzy backups). In contrast with a crisp backup, which is taken while the VSAM file is closed to all processes other than the backup process, a fuzzy backup is taken while the VSAM file remains open to transaction updates. A fuzzy backup is combined with relevant records of transaction updates during file recovery.

To create BWO backups, you implement the BWO feature in the environment, enable the BWO backup method, and execute the RUV Backup function for the file or group of files.

For more information, see Creating-BWO-backups.

Instant Snapshot copies

You can use the RUV Backup function to produce Instant Snapshot copies through the use of the BMC Software SNAPSHOT UPGRADE FEATURE for VSAM component, which works with the technology that is available with intelligent storage devices. You can also make an Instant Snapshot copy of a sequential file. An Instant Snapshot copy is a physical duplicate of a file without paths and alternate indexes. The copy process is nearly instantaneous, regardless of the size of the data set. An Instant Snapshot copy can also be restored in seconds, and RUV rebuilds paths. RUV automatically recognizes and handles an Instant Snapshot copy during restore and forward recovery processes.

For more information, see Creating-Instant-Snapshot-copies.

Sequential file backups

RUV gives you the ability to backup and restore sequential files, as well as VSAM files.

With this feature, you can

  • Keep your sequential files generally in sync with your VSAM files
  • Have the backup information for all your important files stored in the RUV repository

RBA0 backups

Through the RBA0 backup detection feature, RUV can detect that a VSAM file is empty and register a RBA0 backup at that point in time. It can also register an RBA0 backup when a file that has been defined with the REUSE option is opened for output. (This action causes the high used relative byte address to be reset to zero, which effectively deletes all records in the file.)

An RBA0 backup is simply a record in the repository; no physical data set is associated with an RBA0 backup. However, an RBA0 backup is intended to be used, in the same way as any other type of backup, as a starting point for recovery.

For more information, see Using-the-RBA0-backup-detection-feature.

SMS and IDCAMS backups

RUV can automatically handle existing Storage Management Subsystem (SMS) backups of files. You do not need to register SMS backups in the repository for RUV to select and restore them as appropriate for the situation. RUV does not invoke SMS to perform backups.

RUV can automatically restore backups that are produced with the IDCAMS utility REPRO command. You must use the REGISTER BACKUP_FILE command to register the backups in the RUV repository explicitly; you can set up the backup job to perform this registration automatically.

For more information, see Using-SMS-backups-and-IDCAMS-REPRO-copies.

External backups

In addition to supporting backups that are produced by RUV, SMS, and IDCAMS, RUV fully supports and automates the use of external backups that are created by other processes and vendor products. RUV can submit the JCL that executes the external backup process and registers the external backup in the repository. During the restore process, RUV can submit the JCL that restores the file from the external backup or issue a request to the operator that provides the necessary information for the file to be restored manually.

For more information, see Creating-external-backups.

Backup strategies

The following topics relate to the strategies you can use for backups. For a complete discussion about general backup strategies that you might employ, see Managing-backups.

Group backups and individual file backups

You can manage backups individually for each file, collectively for groups of VSAM files or groups of sequential files, or in any combination of individual and collective management that suits your environment. RUV groups simplify the setup of backup processes and ensure consistent activity for related files.

As much as possible, RUV performs backups for the files in a group in parallel, which minimizes the elapsed time for completing the backup process and maximizes the effective use of available resources. If you specify individual files for backup in a single job step, RUV performs the backups serially in the order that you specify them.

If you specify a group for backup, RUV resolves and expands the group into its component file names; this expansion is based on the file names that are recorded in the RUV repository at execution time. The expanded group of files can be backed up in parallel to DASD, multiple tape drives, or stacked tapes, providing you with superior tape usage.

Backup data sets that were created by a VSAM group backup process can be used for individual file restore or recovery, as well as for VSAM group restore and recovery. Backup data sets that were created by a sequential group backup process can be used for individual file restore, as well as for sequential group restore.

Most RUV backup management commands allow you to specify RUV groups. Information about using groups with those commands is included in this section. For more information about defining groups, see Defining-VSAM-groups.

Copies of backups

Depending on your backup strategy, you might need multiple copies of a backup data set (for example, you might want to keep one copy onsite for application recovery and send one copy offsite for disaster recovery), or you might need a copy in a different format (for example, you might want to create a traditional backup from an Instant Snapshot copy).

RUV can produce multiple copies of the backup data set during the backup process, register the copies, and mark the copies with a status that indicates their eligibility for restore processing.

Warning

Note

You should set an active status for only one of multiple copies for each VSAM file. For copies that you plan to send off-site, set the status to inactive so that RUV refers only to the primary backup copy at the local site.

You can also use the RUV COPY BACKUP command or the IDCAMS REPRO command to copy backup data sets in a separate process at any time after the backup process completes. For RUV to recognize and use copies that you create with the REPRO command, you must register them explicitly. RUV implicitly registers copies that you create with the COPY BACKUP command.

For more information, see Creating-copies-of-backups.

Backup environment options

Backup environment options control how RUV handles backup-related concerns, such as which backup methods you want to enable, whether to perform incremental backups, and how long to keep backup registration records in the repository.

For more information, see Controlling-backup-environment-options.

Backup registration records in the RUV repository

To manage backups, RUV maintains backup registration records in the RUV repository.

Registration of backups

For RUV to be able to use most types of backups (except SMS backups), the backup must be registered. RUV creates a backup registration record that contains all the information that RUV needs for identifying and using the backup, including the backup data set name, the data set name of the original file that was backed up, the time when the backup was created, and the backup method that was used to create the backup.

RUV registers RUV backups, Instant Snapshot copies, and RBA0 backups implicitly during the backup process. (Implicit registration means that you do not use the REGISTER command.) RUV also implicitly registers copies of backups that are created with the COPY BACKUP command. RUV detects and uses SMS backups automatically without a backup registration record in the repository.

For RUV to create a backup registration record in the repository for IDCAMS backups and external backups, an explicit REGISTER command is required. You can automate registration in the backup job by including a step to execute the REGISTER command. You can also use the REGISTER command as needed to create or recreate a backup registration record (for example, if a backup registration record has been deleted while the backup itself is still needed).

For more information, see Explicitly-registering-backups.

Update, delete, and report functions

In most cases, RUV manages backup registration records in the repository automatically so that no manual tasks are necessary. In certain circumstances, however, you might want or need to work directly with backup registration records. You can use the following RUV commands for backup registration records:

  • Use the UPDATE BACKUP_FILE command to change information in the backup registration record, including the status, location, comments, and registration time. For example, you might need to change a backup registration record from inactive to active status as you prepare for an offsite recovery.
  • Use the DELETE BACKUP_FILE command to delete backup registration records. For example, you might need to delete a backup registration record manually if the backup that it describes has been lost or damaged. Normally, RUV deletes backup registration records when they are no longer needed based on repository purge criteria.
  • Use the REPORT BACKUP_FILE command to obtain a report about the backups that are registered in the repository. The primary use of this report is to determine the results of a command before you execute it.
  • Use the REPORT BACKUP_METHOD command to obtain a report about the backup methods that are enabled in your environment.

For more information, see Working-with-backup-records-in-the-repository.

Considerations for backups

RUV uses a relative byte address (RBA) to identify the records in a VSAM ESDS. Data compression products can change the RBA of an ESDS record as updates occur. Because of the unpredictability of compressed ESDS RBAs, you should exclude these data sets from compression if you want to recover them with RUV.


 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*

BMC AMI Recovery for VSAM 4.1