z/OS DFSMS Managing Catalogs
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Developing a Backup and Recovery Strategy

z/OS DFSMS Managing Catalogs
SC23-6853-00

A primary consideration for backing up catalogs is backup frequency. In general, a catalog recovery takes less time the more recently the backup copy was taken. However, continuously creating backup copies can be a drain on your system. Daily catalog backup should be sufficient for most catalogs.

Backup procedures can be simplified if you are using the Storage Management Subsystem. You can define a management class for your catalogs and other system data sets, defining an appropriate backup frequency. The system then creates backups of the catalog according to your management policy.

Your backup strategy should include running IDCAMS DIAGNOSE and EXAMINE functions against each catalog before you perform a back up. This ensures that you back up only valid catalogs.

The BCS can be backed up as a data set using the EXPORT command, DFSMSdss, or DFSMShsm. The aliases defined for the catalog are saved with the backup copy when EXPORT or DFSMShsm is used, or when logical dump is used with DFSMSdss. When you recover the catalog by importing it, you can have the saved aliases redefined and merged with existing aliases. DFSMSdss and DFSMShsm redefine the aliases automatically. However, when you use the IMPORT command, you must specify ALIAS to have aliases redefined or retained.

Before recovering a BCS, you should lock the catalog to prevent access during the recovery. Before you can lock the catalog, no job can have the catalog allocated with a disposition of OLD. This disposition can be defined on a DD statement. It can also result if the catalog is used in the OUTDATASET parameter of access method services commands. The RACF® FACILITY class profile IGG.CATLOCK must be defined to allow the use of the LOCK parameter with ALTER, DEFINE USERCATALOG, and IMPORT to those users having READ authority to this class. All other access is restricted from LOCK use.

The VVDS and VTOC should not be backed up as data sets, but are backed up as part of a full volume dump using DFSMSdss or DFSMShsm. The entries in the VVDS and the VTOC are backed up with the data sets they describe when the data sets are backed up with the IDCAMS EXPORT command, DFSMShsm, or DFSMSdss logical dump.

There are two ways that a VVDS or VTOC can be recovered:

  1. Restore the volume containing the VVDS or VTOC, or
  2. Rebuild the VVDS and VTOC by recovering the data sets on the volume.

Restoring the volume is the easiest way to recover a VVDS or VTOC. However, this is seldom practical because the data sets restored will not be current. To rebuild the VVDS, you must delete it and then recover all VSAM and SMS-managed data sets which were on the volume.

The VTOC can be backed up with volume dumping, and can be restored by restoring the volume. To rebuild a VTOC, you have to use ICKDSF to initialize the volume. Then, all data (not only VSAM data sets), must be recovered to the volume. Do not try to repair a VTOC by manually rebuilding damaged records.

BCS backups and volume dumps can be stored on DASD or tape. More than one backup should be kept, since the most recent backup might also be damaged.

See z/OS DFSMS Implementing System-Managed Storage for a more extensive discussion of backup and recovery considerations.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014