Data Set Selection

Full volume backup

Naturally, during a full-volume backup, ABR always backs up all data sets on the volume. There are no options to select or exclude particular data sets. The backup also includes the label track, VTOC, VTOCIX, and VVDS (if the latter two exist).

Incremental backup

During an incremental backup (DUMP TYPE=ABR or TYPE=AUTO) data sets are selected for backup from a given DASD volume by the following rules:

VTOC - Always backed up.
VTOC Index (VTOCIX) - Always backed up if it exists.
VVDS - Always backed up if it exists.
Protect List - Data sets named in the ABR Backup Protect List are not included in any incremental backup. The Backup Protect List is defined and enabled by the ABR ISPF Install Dialog described in Define-the-ABR-Protect-Lists-and-Restore-Allocation-List.
SMS Management - If SMSMANAGE=YES is specified on the ABR DUMP statement, the management class of every SMS-managed data set is checked. If the management class specifies that the data set is not eligible for “auto-backup”, it is automatically excluded.
SELECT and EXCLUDE Statements - ABR backs up or excludes any data set selected by the user. SELECT and EXCLUDE control statements override all backup selection rules except for the backup of the VTOC and the PROTECT list. If UPDATE is specified on a SELECT statement, the data set is only dumped if the update (changed) flag is set in its Format 1 DSCB. When both SELECT and EXCLUDE statements are present, EXCLUDE statements must be specified before the SELECT statements.

Warning

If you exclude data sets from incremental backups with the PROTECT LIST, SMS management class, or EXCLUDE statement and they were updated since the last full-volume backup, a full-volume recovery can not properly restore the contents of those data sets.

Temporary Data Sets - ABR does not backup temporary data sets. A temporary data set is defined as a data set whose name starts with the characters “SYS”, and contains a “.T” in position 9 and 10, and a period in position 17.
Updated Data Sets - Unless excluded by the Protect List, SMS, or EXCLUDE statements, ABR backs up all data sets on a DASD volume that have been updated since the last backup. ABR examines the update (changed) flag in the DS1DSIND field of each Format 1 DSCB. If the data set has been updated, it is backed up and the UPDATE bit is reset so that it is not backed up again on the next incremental unless it is updated again. This is the usual way that data sets are selected for incremental backups.
Updated VSAM - IBM only sets the update flag in the DSCB of the base data component, and only on the first volume in the case of multi-volume clusters. Whenever ABR selects any component of a VSAM cluster from a volume, it automatically selects all components of that cluster (including Alternate Indexes (AIXs)) on the same volume. Multi-volume data components, index components on a volume without the data component, and key ranges (all volumes) do not have the update indicator set. ABR always dumps these components if found on the volume, except for an alternate index residing on a volume by itself.
New Data Sets - ABR also backs up a data set if it does not have a current ABR backup. This implies that it was created since the last ABR Volume Backup of this volume.
Catalogs - All catalogs on the volume are backed up.
Remote Queue - ABR supports user requests for data sets to be included in incremental backups even though they have not been updated. Depending on the installation options, when a user requests Remote Queue backup of a data set, it either sets the update flag in the Format 1 DSCB of the data set, or it adds a statement to a Remote Queue data set requesting the backup. In the latter case, options in the ABR backup step control whether these requests are honored.

Rarely closed data sets

As noted above, updated data sets are the bulk of data sets automatically selected by ABR incremental backups (DUMP TYPE=ABR or AUTO). However, special processing is required for data sets that remain OPEN for a long time.

ABR depends on the update flag in the DSCB (DS1UPDAT) to indicate data sets that have been updated. This flag is set whenever a data set is OPENed for OUTPUT or UPDATE and ABR turns off the flag when it backs up the data set. If the flag is on again the next time that ABR incremental backup is run, ABR knows it has been updated again and backs it up again.

However, if the data set remains open for many days, the update flag is set only when it is first opened. ABR turns it off when it backs it up, but it is not set again as long as the data set remains open. So the next time the ABR incremental backup is run, ABR does not see the update flag and does not back up the data set again.

To solve this problem, you need to identify data sets that are in the “rarely closed” category and include SELECT statements for them in the ABR incremental backup job streams.

Data sets in the rarely closed category might include:

Some system data sets
Data sets used by some ISV software, such as tape management
Data sets used by online systems that are active for days at a time
Data sets used by database systems that may remain active for days at a time

Data set backup

ABR Volume Backup includes an option to only backup specific data sets. This is requested by TYPE=DSF on the ABR DUMP statement. In this mode, SELECT and optional EXCLUDE statements specify the data sets to be included in the backup. No other data sets (not even the VTOC) are included. However, be aware that if you include TYPE=DSF runs with regular incremental backups, ABR full-volume recovery may not work correctly. However, you are able to restore individual data sets from any type of volume backup.

Full-Volume recovery

ABR Full-volume recovery from Volume Backups does not recover individual data sets. Instead, it reads the most recent incremental backup to recover the most recent copy of the VTOC, VTOCIX, and VVDS, so that all data sets appear to be at their most recent locations. Then it recovers the most recent copy of every allocated data track, starting with the most recent incremental backup and working backwards to the full-volume backup that started the generation. So, if a data set was backed up on several different incremental backups, only the data from the most recent backup is restored.

To determine the backups that must be read, ABR does the following:

If the volume being recovered still exists and is readable, it reads the ABR Model DSCB from that volume. That DSCB contains the generation and cycle numbers of the most recent backup for that volume. The recovery starts with that last generation/cycle and work backwards to cycle 00 (full backup).
If the volume is not accessible or the ABR Model DSCB does not exist, ABR searches the ABR catalog for the most recently created backup for this volume, based on the date of the catalog entry. The recovery starts with the generation/cycle of that backup and work backwards to cycle 00 (full backup). Since you usually do full-volume recovery after a hardware failure, or at a disaster site, this is the most frequently used technique.
If you want to recover starting with a cycle other than the most recent, or recover from a generation other than the current generation, you can specify the generation and/or cycle number to be recovered.

Warning

If you use the DEFRAG function of IBM's DFSMSdss product to consolidate free space on volumes for which you do incremental backups, the ABR Full-Volume Recovery does not work properly. ABR is dependent on the location of data sets to properly reconstruct the volume, so when a data set's location is moved, it must be backed up again on the next incremental backup to enable proper full-volume recovery. DEFRAG does not turn on the UPDATE flag in data sets that it moves, so ABR does not know that they need to be included in the next incremental. If you must use DEFRAG, run it immediately before the ABR full-volume backup (TYPE=FDR) for the volume. A better choice would be to use COMPAKTOR (COMPAKTOR-CPK-DASD-Volume-Reorganization) that does set the UPDATE flag for all data sets moved.

Data set restore

Since the ABR Volume Backups are standard FDR backups, you can restore any individual data set from these backups. For recently created backups, ABR can automate the entire restore process, so that you do not have to have any knowledge of which generation and cycle contains the backup that you want restored; you usually do not even have to know what DASD volume it was on.

As described in FDRABR-Volume-Backups, ABR Volume Backup records the most recent backup of each data set in fields in the Format 1 DSCB of that data set. Actually, it only records the cycle number that contains that backup; since that cycle must be part of the current generation, the current generation number is obtained from the ABR Model DSCB on the volume, and the DASD volume serial completes the information necessary to construct the name of the ABR backup file on tape. That name is then located in the ABR catalog and the required tape is mounted.

For volumes that have been initialized with the OLDBACKUP option in the ABR Model DSCB (see FDRABR-Volume-Backups), ABR also records up to 13 previous backups of a given data set. Every time a data set is backed up by Volume Backup, the last “current backup” is moved into the most recent “old backup” slot and the rest of the old backups shifted down, losing the oldest. If you need to restore a backup other than the most recent, you can either request it by relative backup number (0=current, 1=next oldest, and so on) or display the recorded backups under ISPF and select the version desired. For volumes where OLDBACKUP is not enabled, ABR can only restore the most recent backup automatically.

Since you may wish to restore the backup of a data set that has been scratched (deleted) from DASD, making its Format 1 DSCB unavailable, ABR has an optional facility called the SCRATCH catalog. Details of enabling the DADSM Preprocessing exit, which implements the SCRATCH catalog, are found in DADSM Pre-Processing Exit in . When the exit is enabled, and a data set that has a current backup recorded in its Format 1 DSCB is scratched or renamed, the exit extracts the backup information (the current backup plus up to 3 previous backups if present) and record that information as a catalog entry in the SCRATCH catalog (which is usually the same as the ABR catalog).

To automatically restore a data set from a Volume Backup, ABR must find the Format 1 DSCB (VTOC entry) of that data set, since backup information is kept in the F1 DSCB. First, ABR must determine the DASD volume serial from which the data set was dumped. If you do not provide the volume serial, ABR searches the catalog for the data set and gets the volume serial from the catalog entry. ABR then reads the F1 DSCB of the data set from the VTOC of that volume to determine the generation and cycle of the required backup, either the current backup or an older backup.

If the data set was not found in the catalog or in the VTOC, or it has no current backup recorded or the volume was offline, ABR searches the SCRATCH catalog if enabled. If you specified a volume serial, the search is successful only if it is recorded as being scratched or renamed on that volume serial; otherwise, it selects it from the SCRATCH catalog no matter what volume it was scratched from.

If you know the particular volume serial and backup generation and cycle numbers which contain the backup of the data set you want, you can specify this information via the VOL=, GEN=, and CYCLE= operands on the SELECT statement. ABR still locates that backup in the ABR catalog and mount the required tape.

When restoring a data set from Volume Backups, the original data set often still exists on DASD. In that case, by default, ABR simply overlays the existing data set with its earlier contents. However, if it is not currently on DASD, or if you force the restore to a new volume or a new data set name, the restore process is identical to that of FDRDSF. Please review Data Set Restores in DSF-Technical-Summary for details on allocating, restoring, and cataloging data sets during the restore. Set-RESTORE-Statement contains details on output volume selection for ABR restores.

The data set restore process above works only when you are requesting specific individual data sets. If your SELECT statement specifies a mask (for example, SELECT DSN=PAYROLL.**) or SELECT ALLDSN, ABR requires that you identify one particular backup data set (either a full-volume backup or an incremental backup, from one particular DASD volume) to scan for the data sets. In this case, ABR does not locate the F1 DSCB, nor does it check the SCRATCH catalog; only that one backup file is read. You can identify the backup by VOL=, GEN=, and CYCLE= as mentioned above.

However, if the data sets to be restored are still cataloged, you can use a catalog mask (for example, SELECT CATDSN=PAYROLL.**). CATDSN scans the system catalogs for data sets matching the mask and internally generates a SELECT DSN=dsn,VOL=vol for each, so it locates their backups in the F1 DSCB or SCRATCH catalog.

The ABR Restore Protect List, documented in Define-the-ABR-Protect-Lists-and-Restore-Allocation-List, can list data sets or groups of data sets that are not to be restored, similar to EXCLUDE statements. Any attempt to restore those data sets from Volume Backups or Archive Backups fail (except for full-volume recovery from Volume Backups).

For details about allocating and cataloging restored data sets, see Cataloging Non-VSAM Output Data Sets in DSF-Technical-Summary.