Create a backup of your RACF database

Creating a backup of the RACF database is recommended whenever significant changes are being made to RACF and the RACF databases.

There are two utilities you can use to create a backup database:
  • IRRUT200 serializes on the RACF® database and creates an exact, block-by-block copy of it.

    This exact copy can help performance when you are maintaining statistics on your backup database. IRRUT200 can be used only if you are creating a backup database that is the same size and on the same device type as the input database. If you specify PARM=ACTIVATE in your JCL, IRRUT200 activates the backup copy without allowing the RACF database to be updated between the copy and activate operations, keeping the backup and primary data sets synchronized.

  • IRRUT400 creates a copy of your database and can be used to change its size.

    IRRUT400 also reorganizes the contents of the output RACF database. Use this utility if you are copying between different device types. You can also use IRRUT400 to extend the RACF database before it becomes full.

Start of changeIt is important to use the RACF-provided utilities when copying an active RACF database, because they serialize to protect the data in your database. If, however, your database is inactive, you can use other block copy utilities, such as IDCAMS REPRO.End of change

Options for updating backup databases

The RACF data set name table specifies the data set names for both the primary and backup RACF databases, and the recovery option. If the primary database is split, you specify several pairs of entries. If you elect to use the RACF data set name table, you can choose from three backup options:

  1. All updates duplicated on the backup database

    When you update the primary database, the backup database is also updated. If you choose this option, your backup database must be a copy of the primary database that existed at RACF initialization. Switching to this backup database is transparent to the users.

    The cost, in terms of RACF processing for this option, is high if you use many discrete profiles and do not use SETROPTS RACLIST processing.

  2. All updates, except for statistics, duplicated on the backup database
    This option is similar to the first option, except that changes you make to the primary database for the sole purpose of updating statistics are not made on the corresponding backup database. If you are maintaining statistics on the primary database and you must switch to the backup database, you might lose some statistics.
    Note: However, if SETROPTS INITSTATS is on, a limited subset of statistics is maintained on the backup.

    The cost, in terms of RACF processing for this option, can be appreciable if a high proportion of your activity is changing RACF profiles. However, the overhead is less than for the first option, and your backup database is current in the event of an error on your primary.

    Guideline: Use this option in your data set name table.

  3. No updates duplicated on the backup database
    With this option, your backup database is allocated but inactive. When you make changes to the primary database, the corresponding backup database is not updated. If you switch to this backup database when there is a failure in your primary database, you bring a down-level RACF database into operation.
    Note: If you activate the backup database, RACF will start recording the updates on the backup.

    The cost, in terms of RACF processing for this option, is negligible, but system operation and recovery could be difficult, depending on how out-of-date the information in the database is.