FDRABR overview

ABR

Program FDRABR (Automatic Backup & Recovery (ABR®)) automates the execution of FDR full-volume and data set backups and restores for the purposes of:

Data availability

Creating backup copies of DASD data sets to protect against physical or logical loss.

Space management

Identifying data sets that do not need to be on DASD (usually based on the last date they were used) and moving them to backups, from which they can be automatically recalled if needed. Data sets that are never needed again can be scratched without creating a backup.

Disaster recovery

Creating backups from which all or part of your DASD data can be quickly recreated at a disaster recovery site.

This is accomplished by the use of several ABR functions, as described in the following:

ABR backups

All the backup functions of ABR share these common characteristics:

The backups are in standard full-volume (FDR) or data set (DSF) backup format, described in Full Volume Backups. Data can be restored from ABR backups with FDR, FDRDSF, or ABR itself. SAR can be used to restore from ABR full-volume backups.
Although ABR backups still require a separate backup data set for each DASD volume processed, ABR automatically stacks multiple backup data sets on tape, creating multi-file tapes, to make best use of today’s high-capacity real and virtual tape storage devices. If necessary, multiple output tape volumes are used. No special JCL is required since ABR handles the file creation internally.
ABR backups to DASD are also supported. ABR automatically allocates the backup data sets on the backup volumes you specify.
The output devices (tape and/or DASD) are specified in the ABR batch JCL. However, you only need to identify the output device; ABR automatically names and creates every backup data set and catalog it if required.
You can specify in the JCL that two copies of each backup are to be created, even though the input DASD is read only once. This is often used to create one copy for on site recovery and a second for off site storage for disaster recovery.
If multiple output devices are specified in the JCL, ABR automatically uses internal sub-tasking to backup more than one DASD volume concurrently.

ABR Volume Backups and Restores

ABR Volume Backups consist of full-volume and incremental backups which allow you to create daily backups of your DASD volumes, so that you can do anything from restoring individual data sets to recreating entire volumes. However, you do not have to backup all the data every day. A daily full-volume backup of each of your DASD volumes would be too time-consuming, so users who do not have a product like ABR usually content themselves with weekend full-volume backups and leave themselves open to a weeks worth of updates lost if a failure or disaster occurs late in the week.

With ABR volume backups, you get the effect of daily full-volume backups without the elapsed time associated with them. You must still do periodic full-volume backups (almost all users do them on weekends, but you can schedule them to suit yourself; they do not even have to be weekly). On a daily basis (or sometimes more than once a day), you do an ABR incremental backup which only backs up the data sets which have changed or been created since the last backup of the volume, plus the label track, VTOC, VTOCIX, and VVDS. These incremental backups are accumulated and are kept at least until the next full backup is executed.

If you have DASD failures, or have to restore at a disaster site, ABR automates the restore process. It locates the most recent full-volume backup (or an earlier one if you prefer) and all the incremental backups that followed it. ABR then reads the most recently-created incremental, restoring the label track, VTOC, VTOCIX, VVDS and any data sets on that backup. It then reads back through the preceding incremental backups and the full backup, restoring the most recent copy of each data set. The result is a volume which looks exactly like the original volume did at the time of the last incremental. All data sets are in their original locations, with the exact same allocation characteristics.

If you need to restore individual data sets, ABR tracks which full or incremental backup contains the most recent backup of each data set. Restore is as simple as providing the data set name; ABR will locate and dynamically allocate the proper backup and restore the data set; the restored data set can be renamed and/or directed to a new volume, but by default it is restored to its original volume with its original name. ABR has an option to track up to 13 previous backups for every data set, allowing you to easily restore earlier versions. ABR data set restores follow the same rules as DSF restores described in Data Set Restores.

ABR volume backups do not use a database for recording the backups. Information about backups is stored in four places:

1.Every volume to be processed for ABR backups must have a special DSCB in the VTOC of the volume, known as the “ABR Model DSCB”. It is called a model because the data set has no extents and occupies no tracks on the volume, similar to the model DSCB used with Generation Data Groups (GDGs). The DSCB itself is used for recording data about volume backups for that volume, such as the date of the most recent backup. An ABR utility is used to create the ABR Model DSCB.

2.The backup data sets created by ABR are cataloged in a standard operating system catalog. They have a standard name format starting with a specified high-level index (default is FDRABR) that is usually assigned to a separate catalog, known as the ABR catalog.

3.Information about the backups of individual data sets is stored in reserved fields of the Format 1 (F1) DSCB of each data set on DASD.

4.For data sets that have been scratched, so that their F1 DSCB is no longer available, ABR records backup information in a special operating system catalog entry, called the “scratch catalog” entry, usually part of the ABR catalog.

During restore, ABR uses this information to construct a list of the backup data sets that must be read. In almost all cases, it dynamically allocates the restore backup data sets (on tape or DASD) and reads them.

ABR volume backups are designed to allow you to recreate entire DASD volumes, or to restore backup copies of individual data sets. Details on ABR volume backups are found in ABR Volume Backups.

FDRINSTANT

If you are also licensed for FDRINSTANT, it enhances FDRABR Volume Backups to provide the ability to take backups that are frozen at a given point-in-time. This works with special facilities available on some DASD subsystems, namely TimeFinder and FlashCopy on the EMC Symmetrix, ShadowImage on the Hitachi Vantara DASD, and FlashCopy on IBM and other vendor DASD. It allows you to capture a point-in-time image of an online DASD volume to an offline DASD volume, effectively capturing the image of the online DASD volume at that point-in-time. ABR can then read the offline DASD volume and create the required backups or copies, without relabeling the DASD volume or bringing it online. ABR can also restore from the offline DASD volume if necessary. FDRINSTANT for SnapShot, TimeFinder, ShadowImage, and FlashCopy is described in:

FDRDRP

If you are also licensed for FDRDRP (Disaster Recovery Program), this restore program manages full-volume recoveries from ABR volume backups (incremental and full-volume backups) by mounting each required backup tape as few times as possible, often only once per tape. This is usually used at disaster recovery sites. Details are found in FDRDRP.

ABR application backups and restores

ABR application backups (FDRAPPL), as their name implies, are designed to backup all the data sets that relate to a given application, on whatever DASD volumes they reside. Since application data sets are usually cataloged, you can have ABR search the operating system catalogs for data sets matching one or more name masks, quickly and easily selecting the data sets and their cataloged volumes to be processed.

Application backup will process all of the data sets selected on the volumes selected. Since ABR always creates one backup data set per DASD volume, it will automatically stack multiple backup files on the output tape, depending on how many DASD volumes were read. Usually a single tape is used for output; creating one tape with all the selected data (a duplicate backup can be created).

Application backup does use a database to record the data sets that were backed up. This database is called an Application Control File (ACF); it has the same format as the Archive Control File described below. The ACF is compact, recording several hundred data sets in a single track.

If data sets must be restored from an application backup, the information on their location is read from the ACF to build a list of backup data sets to be dynamically allocated and read. You can select the data sets to be restored, or simply restore the most recent copy of every data set in the ACF.

There are several ways of managing the ACF:

You can create a new ACF every time that you execute application backup. It will contain only the data sets that were backed up in that ABR run. Usually a copy of the ACF will also be written to the backup tape, making the tape self-contained so that you can easily restore at a disaster site.
You can use a permanent ACF for each application. This records all backup copies of each data set that is part of the application. Usually you need to backup and restore the ACF with another facility (such as ABR incremental backup) so that you can restore the application at a disaster site.

ABR Application backup provides for backup and restore of the data sets belonging to one application. Working-with-FDRAPPL describes this function in detail. You can license FDRAPPL separately without licensing all of ABR, but you must be licensed for FDR.

ABR Archive and Auto-Recall

ABR Archive is used for space management, by moving data sets that are not currently required to be online from expensive DASD to less expensive medium such as tape, VTS, DLm, VTL, or DASD (in a highly compressed format).

The DASD volumes to be processed by archive must contain an ABR Model DSCB (see ABR Volume Backups and Restores). Archive does not record anything in the ABR Model DSCB, but there is a flag enabling or disabling each volume for archiving. The data sets moved from DASD by ABR Archive are recorded in an Archive Control File (ACF). The ACF is a Direct Access (DA) data set that can record several hundred such archived data sets in a single track. There is usually one common ACF for all archived data sets

You can specify various criteria for selecting the data sets to be archived, such as “not cataloged” or “not used in the last 15 days”. Different criteria can be specified for various data sets (by volume, by data set name mask, or a combination).

A data set that has been archived can be marked as eligible for automatic recall (“auto-recall”). With auto-recall, the catalog entry for an archived data set is left in the operating system catalog, with a special indicator that indicates that it was archived. When an archived data set is referenced by batch JCL, dynamic allocation, or TSO, an ABR Catalog Locate exit detects the indicator and automatically “recalls” the data set to DASD before it is needed, so the use of archived data sets is transparent to the job or user.

TSO users normally have the option of bypassing the recall, and have a choice of waiting for the recall to complete (foreground) or doing the recall in a separate started task while they do other work (background). TSO users may also add recall requests (and some other ABR requests such as Archive) to a “remote queue” data set that is processed by a batch ABR job.

ABR Archive can be used to implement the IBM concept of Tape Mount Management (TMM) where data sets that are normally on tape are directed to SMS-managed DASD instead, and then moved to tape using ABR. This allows many such data sets to be stacked on tape and uses far fewer tape volumes.

ABR Archive is described in detail in Working-with-FDRABR-Archiving-and-Superscratch.

ABR Superscratch

ABR Superscratch operates exactly like ABR Archive, but it does not backup the selected data sets, it simply deletes them. Superscratch can be used to delete data sets that you know will never be needed again (such as temporary data sets). There is a separate flag in the ABR Model DSCB to enable a volume for Superscratch.

ABR Superscratch is described in detail in Working-with-FDRABR-Archiving-and-Superscratch.

Simulation

Almost all functions of ABR can be run in simulation mode, allowing you to verify that the correct data will be selected when run for real.

ABR Utilities

ABR includes several utility programs, FDRABRM for setting options on DASD volumes, FDRABRCM for maintaining the ABR catalog, FDRARCH for maintaining the Archive/Application Control File, FDRTSEL for automatic movement of ABR backups, and FDRABRP for simple reporting. ABR also includes FDREPORT (see FDREPORT) for more sophisticated reporting.

FDRCRYPT

If you are also licensed for FDRCRYPT, it enhances all types of FDRABR backups and restores to optionally create and restore backups encrypted by one of several public (symmetric) key encryption algorithms, including Advanced Encryption Algorithm (AES).

FDRCRYPT also enhances FDRTSEL to allow you to copy encrypted backups, including the ability to create an encrypted backup from an unencrypted backup, an unencrypted backup from an encrypted backup, or to change the encryption type while copying.

FDRCRYPT is described in Working-with-FDRCRYPT-Backup-Encryption.