Overview of FDRABR Volume Backups

ABR

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

• Data availability - Creating backup copies of DASD data sets to protect against physical loss or logical damage.
• 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 (called “archiving”), 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.
• Tape mount management (TMM) - Maximizing tape volume usage by staging small tape data sets to a DASD buffer, then moving many of them to a tape volume.

These objectives are accomplished by the use of several ABR functions:

• This section describes ABR Volume Backups (DUMP TYPE=FDR, ABR, AUTO, and DSF) that are used for “data availability” at the volume level.
• ABR ARCHIVE (DUMP TYPE=ARC) and Superscratch (DUMP TYPE=SCR) are found in FDRABR-Archiving-and-Superscratch.
• FDRAPPL Application Backup (DUMP TYPE=APPL) is in FDRAPPL-Application-Backup.

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 in FDR-DASD-Management-System. If necessary, data can be restored from ABR backups with FDR or FDRDSF, but ABR automates the restore process. Stand Alone Restore (SAR) can also be used to restore from ABR full-volume backups without an operating system.
• Although ABR backups 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 tape volumes. 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. However, DASD backups are rarely used with Volume Backups.
• 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. In ABR, these are known as COPY 1 and COPY 2 (see Volume-DUMP-Job-Control-Requirements). The ABR utilities FDRTCOPY and FDRTSEL (FDR-and-ABR-Backup-Maintenance) can be used to create COPY 2 and also COPY 3 through COPY 9.
• 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

ABR Volume Backups have two purposes:

1. They provide the ability to quickly and easily recreate entire DASD volumes that have been lost due to hardware problems or other damage. At a disaster recovery site, you can quickly recreate the volumes necessary to run your system.
2. They allow the restore of recent backups of individual data sets, specifying only the data set name.
   ABR Volume Backups allow the creation daily backups of all of your DASD volumes (or a subset if you wish). 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 loss of a weeks’ worth of updates if a failure or disaster occurs late in the week.
   ABR Volume Backups consist of:

• 
  
  • Full-volume backups that include all data sets that reside on each DASD volume processed. Most users do full-volume backups once a week, but you can run them on whatever schedule suits you. However, you must do a full-volume backup of each DASD volume involved periodically; we recommend that you do this at least once a month. If you do not have time on weekends to backup all your volumes, ABR includes a facility to select certain volumes each day for full-volume backups, doing incremental backups on the rest.
  • Incremental backups that backup only those data sets that have been updated since the last ABR Volume Backup (either full or incremental) was run, plus descriptive data such as the VTOC, VTOCIX, and VVDS. As described later under “ABR Volume Restores”, these incremental backups are sufficient to recreate an entire volume exactly as it existed when the last backup was taken, yet the elapsed time of the backup is much less than that of a full-volume backup (depending on the amount of data updated). This allows you to create daily backups of your DASD volumes, so that you can do anything from restoring individual data sets to recreating entire volumes. Most users run incremental backups once a day, except on the day that the full-volume backup is scheduled. Incremental backups must be kept at least until the next ABR full-volume backup is run.

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

• 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 GDGs. The DSCB itself is used for storing options for ABR processing of the volume and 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; this is also known as “initializing” the volume for ABR processing but it does not disturb any data sets already on the volume.
• The backup data sets created by ABR are cataloged in a normal z/OS catalog. The backup data sets have a fixed naming convention starting with a specified high-level index (default is FDRABR) which is usually assigned to a separate catalog known as the ABR catalog. Details of the name are described later.
• Information about the backups of individual data sets are stored in reserved fields of the Format 1 (F1) DSCB of each data set on DASD.
• For data sets that have been scratched, so that their F1 DSCB is no longer available, ABR records backup information in a special z/OS catalog entry, called the “scratch catalog” entry, usually part of the ABR catalog.

FDRINSTANT

FDRINSTANT is a separately priced member of the FDR family that enhances FDRABR to allow you to take “instant” point-in-time volume backups of online DASD volumes with minimal disruption of normal processing. It requires special hardware features available in some DASD subsystems. This section does contain brief descriptions of the enhancements present when ABR and FDRINSTANT are both licensed. FDRINSTANT is described in detail for each supported hardware platform:

• EMC Symmetrix with the TimeFinder feature – described in FDRINSTANT-for-EMC-TimeFinder.
• Hitachi Vantara DASD with the ShadowImage feature – described in FDRINSTANT-for-Hitachi-ShadowImage.
• IBM and other vendors with the FlashCopy feature – described in FDRINSTANT-for-FlashCopy.

ABR volume restores

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 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 that 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.

Restoring an entire DASD volume is simple; just provide the volume serial. ABR identifies and mounts all of the backup tapes required. Multiple DASD volumes can be restored in one ABR job, one at a time, or multiple ABR jobs can be used to do the restores in parallel as long as the same backup tapes are not required for two restores.

ABR data set restores

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 locates and mounts 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 DSF-Technical-Summary.

If more than one data set (or a multi-volume data set) is requested, ABR uses the backup information for all requested data sets to construct a list of the backup data sets that must be read. In most cases, it dynamically allocates the restore backup data sets (on tape or DASD) and reads them. Tape backups are sorted; if multiple backup files on the same tape are required, they are read in order without dismounting the tape in between.

FDRDRP

FDRDRP is a separately licensed enhancement to FDRABR. It is described in detail starting in FDRDRP.

FDRDRP is a full-volume restore program, with the same result as an ABR full-volume restore, but it manages the backup tapes to minimize tape mounts and reduce the elapsed time of the restores. Normal ABR full-volume restore does one DASD volume at a time, and may mount an input tape multiple times. FDRDRP does many DASD volumes in parallel and mounts input tapes a minimum number of times (often only once).

Generations and cycles

In order to name the backup data sets created by ABR Volume Backups and to record those backups, ABR uses generation and cycle numbers.

The Generation Number associated with a given DASD volume is incremented every time an ABR full-volume backup of that volume is taken. The first backup of a volume (which must be a full-volume) is generation 1, the next full-volume backup is generation 2, and so on.

Within each generation, backups are assigned Cycle Numbers. The full-volume backup that starts a generation is always cycle 00. Subsequent incremental backups increment the cycle number, so the first incremental after the full-volume is cycle 01, the next is cycle 02, and so on. The maximum cycle number is 63; if a full-volume backup is not run before the cycle number reaches 63, a full-volume backup is forced in place of the next incremental backup.

The most recently used generation and cycle numbers for a given DASD volume are stored in the ABR Model DSCB on that volume, so ABR always knows the next cycle number or generation number to be used when you run a Volume Backup.

Volume initialization

A DASD volume must be initialized for ABR processing before it can be processed by ABR Volume Backup. You initialize a volume for ABR by executing an ABR utility to place an ABR Model DSCB in the VTOC of the volume. 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 GDGs.

The ABR Model DSCB can be created with the ABRINIT statement of the utility FDRABRM, described in VTOC-Maintenance-Utility-FDRABRM. It can also be created with the ABR ISPF dialog (option A.I.8) as described in FDRABRM-ISPF-Interface; this is the preferred method.

The presence of the ABR Model DSCB is sufficient to enable the volume for ABR Volume Backups. It is used for several purposes: it contains defaults and options used by Volume Backups, such as the retention period and the number of generations to keep, and it also contains values updated during the backup, such as the latest generation and cycle numbers and the expiration date of the last full-volume backup. The defaults and options can be changed at any time by FDRABRM or ISPF option A.I.8.

The ABR Model DSCB has a name of FDRABR.Vvolser where “volser” is the volume serial of the volume. “FDRABR” is the default first index; you can change it during installation of ABR but once you start running ABR backups you can no longer change it without losing all of your previous backups.

On non-SMS volumes, the ABR Model DSCB is an uncataloged data set, but on SMS-managed volumes, it is cataloged to meet SMS requirements. When converting ABR initialized non-SMS volumes to SMS-managed, use the FDRCONVT utility described in FDRCONVT-Overview since the IBM CONVERTV function does not convert the ABR Model DSCB properly.

Tape format and naming conventions

The backup files created by ABR Volume Backups are in standard FDR (full-volume) or DSF (incremental) format. In this format, each backup file can contain data only from one DASD volume. Therefore, if multiple DASD volumes are to be processed, ABR must create multiple backup files on the output tape. Unless you restrict ABR to processing only a single DASD volume in an ABR step, ABR always creates multiple backup tape files.

Since ABR must be able to uniquely name each tape file, and must be able to record the backup file in a way that it can easily be retrieved, ABR uses a special naming convention for the Volume Backup files. The name contains the DASD volume serial, and the generation and cycle numbers, so each ABR Volume Backup from a given DASD volume has a unique name.

The format is:

abrindex.Vvvvvvv.Cnggggcc

where:

abrindex

Is the ABR high-level index from the FDR Global Options. It is usually “FDRABR”. It can be changed when ABR is installed but must NOT be changed once you start using ABR.

vvvvvv

Is the volume serial of the DASD volume from which the data sets were dumped. ABR creates one backup file for each DASD volume processed in a given ABR run.

n

Is the copy number. ABR always creates COPY1 and can optionally create COPY2. Additional copies up to 9 can be created by FDRTCOPY or FDRTSEL (see FDR-and-ABR-Backup-Maintenance).

gggg

Is the generation number (4 digits).

cc

Is the cycle number (2 digits).

Examples:

COPY1, Generation 0237, incremental Cycle 03 for volume PROD01

COPY2, Generation 0012, full-volume Cycle 00 for volume TSOPK1.

The backup files created by ABR Volume Backup are always cataloged. The high-level index chosen (for example, “FDRABR”) is usually assigned to a catalog designated for ABR use, called the “ABR catalog”. The ABR backups are cataloged like any other non-VSAM data set. If necessary, you can refer to an ABR Volume Backup directly in JCL. However, the ABR restore process makes this unnecessary, since it identifies the required backup data set names, locates their volumes in the ABR catalog and automatically mounts them.

If the backups are on high-capacity tape cartridges ABR records a hardware “block id” in the catalog pointing to the beginning of each backup file. During restores, this block id is used to invoke a high-speed hardware search to position directly to the beginning of the backup file. This significantly reduces restore times.

Backup retention and tape management

Depending on the requirements for recovery established by your installation, you may choose to control the retention of ABR Volume Backups in several ways:

You can let your tape management system expire backups based on a retention period or expiration date. This is known as “date control”.

You can let ABR decide when to expire backups based on the number of generations that exist for a given DASD volume. ABR has no formal interface to any tape management system, but it uncatalogs obsolete generations so you must use the “catalog control” feature of your tape management system.

With no tape management system, the necessary manual procedures for identifying and expiring ABR backups must be established. ABR still uncatalogs obsolete generations.

When a full-volume backup is taken, an expiration date is assigned. It can come from several sources, in this order of priority:

1. If the RETPD= operand is specified on the ABR DUMP statement, ABR uses that to calculate an expiration date that is assigned to all COPY1 (TAPEx) backups created in that ABR step. If the RETPD2= operand is not specified but COPY2 (TAPExx) backups are also created, the same expiration is assigned to those backups.
2. If the RETPD2= operand is specified on the DUMP statement, ABR uses that retention period to calculate an expiration date that is assigned to all COPY2 (TAPExx) backups created in that ABR step.
3. If the TAPEx or TAPExx DD statement pointing to the backup tape contains the EXPDT= operand, the date specified is assigned to all backups written to that DD statement. For some tape management systems this value can also be a keyword; for example, EXPDT=99000 indicates “catalog control” to many tape management systems.
4. If the DD statement contains the RETPD= operand, z/OS uses that to calculate an expiration date, which ABR assigns to each backup written to that DD statement.

When a volume is initialized for ABR processing, a default retention period is specified and is recorded in the ABR Model DSCB. If none of the above RETPD= or EXPDT= operands are given, that default retention period is used to calculate an expiration date that is assigned to the backup of this particular volume. Separate default retentions can be specified for COPY1 (TAPEx) and COPY2 (TAPExx) backups; if the COPY2 default is not specified, the COPY1 default is used for all backups.
By whatever means it is calculated, the expiration date of the full-volume backup is recorded in the ABR Model DSCB. If both COPY1 and COPY2 of a backup are being created, the expiration of each copy is recorded separately in case they are different.

The expiration date is recorded in the tape labels of the backup file and is also recorded by your tape management system, if you have one. If the expiration date is a real date (not a keyword such as 99000) then your tape management system probably returns the tape to scratch status on that date.

The rules are similar for incremental backups, the rules are similar; the first four bullets above apply. However, if none of the RETPD= or EXPDT= operands are given, the incremental backup is assigned the same expiration date as the most recent full-volume backup, as recorded in the ABR Model DSCB. This causes an entire generation, from the full-volume backup that began it to the last incremental, to expire on the same day. If the full-volume backup created both COPY1 and COPY2, and the incremental backup does the same, the expirations of the full COPY1 are copied to the incremental COPY1 for that volume, and likewise for COPY2. If the full-backup only created COPY1, its expiration is copied to all incremental backups of that volume.

If an incremental backup is requested, but ABR detects that the expiration date of the last full-volume backup in the ABR Model DSCB is past, ABR assumes that full-volume backup is no longer available. Since the full backup is required for volume restore, ABR forces a full-volume backup, starting a new generation, in place of the incremental. You must insure that your normal backup procedures request a periodic full-volume backup before the expiration date of the last full backup is reached.

If you have a tape management system, that system usually scratches a backup tape (or multi-volume tape set) when every backup file on the tape has reached its expiration date. Since the backups created on a tape by a given ABR run usually have the same expiration, this is not a problem. However, there are options to place backups with varying expirations on the same tape, so beware of creating files on the same tape whose expirations are widely separated, since this may cause the tape to be retained longer than necessary. The tape management system usually uncatalogs tape files that it expires, so ABR considers an uncataloged ABR Volume Backup to be unavailable. This technique allows your tape management system to decide when to expire ABR Volume Backups.

ABR has an additional mechanism for expiring Volume Backups. Another value that you can specify when you initialize a volume for ABR processing (stored in the ABR Model DSCB) is the number of generations to keep for the volume. Whenever a new generation is started (full-volume backup), ABR subtracts that value from the current generation number, and then uncatalogs that older generation, including all of its cycles and both COPY1 and COPY2. Therefore, if you run your full-volume backups on a regular schedule, such as weekly, you can easily control retention for each DASD volume by setting the number of generations to be kept. This allows ABR to determine when the backups expire if you use the “catalog control” option of your tape management system.

For example, if a DASD volume is initialized for five generations (a month if the full backups are weekly), and incremental dumps are done every weekday, the existing backups might look like:

If a new full-volume backup is taken, it becomes generation 0008 cycle 00, and ABR uncatalogs all cycles (00 through 05) in generation 3. If you use tape management catalog control for these backups, they automatically expire when ABR uncatalogs them.

Although the ABR backups are uncataloged, either by ABR generation processing or by tape management expiration processing, it is possible that some generations or cycles are left cataloged even when they are no longer required. The ABR utility FDRABRCM (see ) includes a PURGE BACKUP function to clean up such orphans. If run with no other parameters, it examines every Volume Backup recorded in the ABR catalog and compare it to the generations limit recorded in the ABR Model DSCB on that DASD volume; backups in generations older than that are uncataloged. You may want to run PURGE BACKUP monthly to be sure no orphan backups are still cataloged.

A combination of these retention techniques can be used. This is usually used to manage the incremental backups differently from the full backups. For example, assume you do weekly full backups and daily incremental dumps and want to keep the backups for the last six weeks. However, since this could occupy many tape volumes, you only want to keep the daily incremental backups for the most recent two weeks, keeping only the full backups for the remaining four weeks. To accomplish this:

• Set the number of generations in the ABR Model DSCB to 6.
• Execute the full-volume backups with catalog control (EXPDT=99000 for many tape management systems).
• Execute the incremental backups with RETPD=14 (two weeks).

Your tape management system automatically expires and uncatalogs the daily incremental backups after two weeks, but the full backups are kept until they are uncataloged by ABR (six weeks). It is also possible to put all the backups under catalog control but accomplish the same thing using the PURGE BACKUP function of FDRABRCM (see Catalog-Maintenance-Utility-FDRABRCM).

If you create both COPY1 and COPY2 of your backups, you can use one copy for on site recovery (for damaged DASD volumes or restore of individual data sets) and the other copy for off site recovery at a disaster recovery site. Most tape management systems include vaulting support, allowing you to select tape to be sent off site and returned when no longer required. Most users send COPY2 off site. Since the data set name used by ABR Volume Backup includes the copy number (described earlier), you are able to easily send COPY2 backups off site while retaining COPY1 on site.

Volume backup execution

To execute ABR and perform Volume Backups, you must create ABR job streams and execute them at appropriate times. Section 50.20 “Volume Backup Examples” contains examples of such job streams that you can customize for your installation.

Since ABR requires periodic full-volume backups, you want to schedule TYPE=FDR backups at regular intervals, such as every weekend or every other weekend, running TYPE=ABR incremental backups on other days. Alternately, you can use TYPE=AUTO to allow ABR to decide when to do incremental and when to do full-volume backups; this can be used to spread your full-volume backups out over the week.

The expiration date test can be overridden by the DATEP=NONE operand on the DUMP statement.

For full-volume recovery, you also need to create ABR job streams; examples are in Full-Volume-Restore-Examples. Since full-volume recovery at your home site is unusual, we suggest that you have a model RESTORE TYPE=FDR job stream which can be modified as necessary. For use at a disaster recovery site, we suggest that you create all the job streams necessary to recover volumes from Volume Backups and send them to off site storage so that you do not have to create them under pressure at the site.

For data set recovery from Volume Backups, there are several alternatives:

• Permit users to restore data sets directly by submitting their own RESTORE TYPE=ABR job. This may require mounting backup tapes for each data set required. If FDR security is enabled, users need UPDATE or ALTER authority to the data sets
• Allow users to add requests to a remote queue (see details in Remote Queue in Processing-Options-and-Requirements). In this case a RESTORE TYPE=ABR job must be run at regular intervals (for example, every hour, every 4 hours) to process any requests on the queue. If multiple data sets are being restored, this minimizes tape mounts. If FDR security is enabled, users need UPDATE or ALTER authority to the data sets.
• Require that users communicate data set restore requests directly to someone in the Data Center, who submits the required RESTORE TYPE=ABR job.

Data-Set-Restore-Examples and SMS-managed-Data-Set-Restore-Examples contain examples of data set restore job streams. For the first two bullets, the ABR ISPF panels support direct restore and remote queue restore, so that users do not need to know anything about ABR JCL when restoring their data sets. Volume-Backup-ISPF-Support for details.