Catalog Backup and Recovery

Backing up Catalogs

Before you work out your catalog backup strategy you need to consider your recovery requirements. If you back level your catalogs at all, then they will be out of step with the datasets that actually exist. The recovery section discusses how to deal with this.
A backup alone does not guarantee that a catalog can be restored, especially if you use IDCAMS EXPORT. You need to check the internal structure of your catalogs too. Most third party products do this as part of the backup, but if you use IDCAMS you should be running an IDCAMS EXAMINE INDEXTEST before the EXPORT, to prove that you are backing up valid data.
You also need to ensure that you are cutting and saving RMF type 61, 65 and 66 records for forward recovery.
And, make sure that your catalog your catalog backups and SMF records in a separate catalog from your user catalogs, to ensure they are available for recovery.
You may have more than one product available to use for backups. The products can be grouped into

   EADM Advert

Accelerate DB2 Write with zHyperWrite and "EADM™ by Improving DB2 Logs Volumes Response Time:

  • IDCAMS - everyone will have this
  • General purpose backup products, such as DFDSS, FDRABR, and SAMS. DFSMShsm is also able to back up catalogs, but you need to ensure that DFSMShsm has access to IGG.CATLOCK in order to be able to work with a locked catalog.
  • Catalog specific products such as Catalog Recovery Plus

Catalogs are absolutely critical to the running of your z/OS system, and you must have a good backup. We recommend you use at least two different methods to backup your catalogs, then you should be able to recover from at least one of them. As everyone has IDCAMS, then one way is to use IDCAMS EXPORT.

//DD1 DD DSN=BKP.catalog.name(+1) etc.
//SYSIN DD *
EXPORT catalog.name -
  OUTFILE(DD1) -
  TEMPORARY

Make sure the backup file of the catalog is not catalogued in the catalog which is being backed up. Ideally, your catalog backups should be duplexed, with each copy catalogued in different user catalogs. You need SMF data to roll forward catalogs, so this too should be duplexed in two different catalogs.

    GFS

You can use IDCAMS to backup RLS managed user catalogs, and two new keywords are available to manage RLS; RLSSOURCE(NO|YES|QUIESCE) and RLSTARGET(NO|YES|QUIESCE).
NO Indicates the source and target data sets will be opened using non-shared resources. (NSR).
YES Indicates that the source and target data sets will be opened using Record Level Sharing (RLS) and the data set will have consistent read integrity.
QUIESCE Indicates that the source and target data sets will be opened using Record Level Sharing (RLS) and the data set will be quiesced before processing any entries. RLS access will be resumed when IDCAMS finishes backup. QUIESCE guarantees data integrity, but means that the catalog is unavailable during backup. A typical IDCAMS statement would be:

EXPORT UCAT.RLSTST OUTFILE(DD1) TEMPORARY -
RLSSOURCE(QUIESCE)

DFSMSdss can be used to backup RLS managed catalogs and it will do the QUIESCE implicitly during backup and enable RLS when the backup is finished. No special parameters are required

Master Catalogs are so critical that its best if a point in time copy is taken and refreshed after every major update. If you cannot do this, then at the very least make sure you have a full volume dump which you can restore using Standalone FDR or DSS.

In general, you do not recover your VVDS as that would make it out of step with the data on the volume, unless you have a specialist catalog management product that will forward recover it to make it consistent with the VTOC. It is possible to recover a VVDS from an FDR or DSS physical volume backup, but it needs special parameters. Consult your product documentation for advice.

Recovering a catalog

Before you consider recovering a catalog, see if the problem can be fixed by identifying and fixing faulty records first. This is usually much easier, quicker and safer.
List the catalog's aliases from each of the master catalogs to which it is connected. You may need to re-create these aliases later.
Run the Catalog Display program to determine whether the catalog is open on each LPAR or system in the sysplex.
Attempt to list the catalog from each system to which the catalog is connected using IDCAMS LISTCAT.
If LISTCAT is successful from systems that previously did not have the catalog open, the the most likely problem is that the control blocks in memory associated with the catalog are in error on the systems from which LISTCAT fails. In this case, close and reopen the catalog on all the systems that cannot access the catalog correctly.
If LISTCAT fails on all systems, the catalog will have to be recovered.

Restoring a catalog is usually quite simple, Recovering it to the point of failure can be complex. Let us assume you have a good catalog backup from 02:00, and your catalog failed at 15:00. The procedure is

  1. Lock or Suspend the Catalog
  2. Restore the catalog to the last backup
  3. Fix datasets which have been created since 02:00
  4. Fix datasets which have been deleted since 02:00
  5. UnLock or Resume the Catalog

Restoring a catalog

Your restore method will obviously depend on what you use to back catalogs up. It is often good practice to lock, then delete the broken catalog before you start, using

  ALTER catalog.name LOCK
  DELETE catalog.name USERCATALOG RECOVERY

The LOCK stops users from trying to access the catalog while you are busy, the DELETE deletes the User catalog and the aliases in the Master catalog, but not the dataset entries. If you use DFDSS or FDRABR logical dumps, then just do a fully qualified dataset restore. If you have an IDCAMS EXPORT, do an IDCAMS IMPORT. These will also restore the aliases in the Master catalog. The IDCAMS statements look like

IMPORT -
OBJECTS(catalog.name VOLUME(volser) DEVICETYPE(3390)) -
CONNECT CATALOG(master.catalog.name)

Forward recovery

Your catalog is now restored to its state at 02:00, but it does not reflect any dataset activity since then. That means that any datasets created since 02:00 exist on disk, but are uncatalogued. Any datasets deleted since 02:00 have a catalog entry, but no VTOC and VVDS entries. It is best to use SMF records, types 61,65,66 created since 02:00 to identify activity to that catalog and use them as a basis to fix, but this can be a daunting task. You must be sure to include the records produced on every LPAR that shares the broken catalog. Another way is to use FDRreport or IDCAMS DCOLLECT to search for uncatalogued datasets. Once you have the list of problem datasets, it is a case of converting these to IDCAMS statements to fix the problem. These will be a combination of

DELETE dataset.name NOSCRATCH for orphan catalog entries
DEFINE CLUSTER NAME(dataset.name) for uncatalogued VSAM files
    VOLUME(volser) RECATALOG
DEFINE NONVSAM NAME(dataset.name) for uncatalogued non-VSAM files
    VOLUME(volser) RECATALOG

New tape datasets can be found by scanning the syslogs for IEC501A M uuuu,PRIVAT,SL,COMP,dataset.name You then need to use an IEFBR14 job to catalog the file up.

Now, does all this sound a bit vague, hazy, not quite there? prone to error? Yes, because this is the hard way to do it. Take a look at the next page which describes products which help take away the pain for catalog recovery

back to top