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. You will have more than one product available to use for backups. The products can be grouped into

• IDCAMS - everyone will have this
• General purpose backup products, such as DFDSS, FDRABR, SAMS
• 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.

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 indentifying and fixing faulty records first. This is usually much easier, quicker and safer. 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 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

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 the 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

                           VENDOR SHOWCASE

Copyright © Lascon Storage Ltd. 2000 to present date. By entering and using this site, you accept the conditions and limitations of use