FlashCopy for ABR

When a normal ABR full-volume or incremental backup completes successfully, it is recorded by doing two things:

• ABR catalogs the backup data set it just created in the ABR catalog.
• ABR updates the VTOC on the volume to record in the ABR Model DSCB the generation and cycle of the backup just created, and updates the current backup information for every selected data set.

So, as soon as the backup data set is complete and available, all ABR records point to it and restores can be immediately requested.

Operation of FDRINSTANT for ABR

With FDRINSTANT, ABR is invoked to capture the point-in-time image and update the online volume immediately. The ABR generation and cycle of the next backup is determined and all of the steps shown above are taken, except that the backup is cataloged to the online volume itself (something that would never occur in a normal ABR backup) so this tells ABR that the backup is a point-in-time image. This functions as a true backup, since you can do restores from it.

Later, ABR processes the point-in-time image and creates a normal ABR backup from the offline image. ABR re-catalogs the backup data set to the tape just created. At this point, the backup looks exactly like a normal ABR backup of the online volume.

Even before the backup is moved to tape, ABR can restore the entire volume or individual data sets from the point-in-time image. No special parameters are required; a normal ABR full-volume or data set restore recognizes that the data it needs is on the offline image and restores it.

Executing FDRINSTANT for ABR

To use FDRINSTANT for ABR, you must divide your existing ABR volume backup jobs into two phases that may be executed in one job or in two separate jobs:

• The first phase captures all the point-in-time images of the selected primary volumes using the ABR statement FCOPY. We recommend that update activity to the online volumes be quiesced during this phase. As soon as it finishes, updates to the online volumes can begin again, since the point-in-time captured image of the volume exists. To insure that the copied volume is not accidentally brought online, ABR modifies the volume label in a way that FDR can access it but any attempt to bring it online (VARY command or IPL) fails. If you have a need to bring the flashed copy online to another system, see Can I Bring the FLASHed Copy Online to Another System or LPAR?
• The second phase creates the actual backup tapes, reading the captured point-in-time images. It is identical to the original ABR step, except that the ABR operand FCOPY= must be added to invoke this support. This ABR step can also include backups of volumes that do not have captured images; these volumes are backed up normally (with a warning message). It also optionally terminates the FlashCopy session when it is done with each volume.

Implementing FDRINSTANT with ABR consists of creating an Instant Phase and Dump Phase. Each phase contains the same JCL and most of the ABR control statements as the original. It is important to ensure that most of the ABR operands specified are used in both phases. The “TYPE=” operand must be identical in both steps. The examples later in this chapter illustrate the changes required.

In the first phase (“Instant Phase”):

• Replace the operation name DUMP on the first ABR control statement with FCOPY. If you have the ONLINE operand, remove it from the FCOPY statement.
• Replace all TAPEx and TAPExx DD statements with a single TAPE1 DD DUMMY statement and a matching SYSPRIN1 DD statement. By default, ABR actually processes up to 10 volumes in parallel and dynamically allocates additional SYSPRINx and TAPEx DD statements using yours as a model. You can override the number of volumes processed concurrently by specifying the operand MAXTASKS=nn with values from 1 to 32.
• If the original ABR step used DISKxxxx DD statements or mount statements with VOLG= or STORGRP= to identify the volumes to be dumped, you must change the FCOPY step to provide one MOUNT statement for each volume to be dumped, since the MOUNT statement provides the unit address of the target volume for each FlashCopy. DISKxxxx DD statements can be left in place; it works with or without them.
• FCOPY uses the default ENQ=RESERVE (instead of the usual ABR default of ENQ=ON) to protect the VTOC during the brief FCOPY operation. We recommend the use of the operand DSNENQ=USE as well so that ABR can properly protect the data sets during the few moments necessary to create the point-in-time image. However, unlike normal ABR operations, where ABR still backs up a data set or volume even if DSNENQ= finds active data sets, FCOPY does not create the point-in-time if it finds data sets in use, which also causes the second step to fail trying to backup that image. You can override this by specifying the ENQERR=NO operand on the FCOPY statement, or by adding statements such as:

SELECT DSN=dsname,DSNENQ=NONE

for data sets that you expect to be active at the time of the FCOPY; this is supported even for FCOPY TYPE=FDR.

• If the backup includes other volumes in other DASD subsystems, or volumes for which you simply do not want to do a point-in-time backup, they are omitted from this step, even though they can be included in the second step.

For example, using this JCL,

After modification, the JCL looks like:

One or more MOUNT statements must be provided to identify each online source volume to be copied (VOL=) and the target device (FLASHUNIT=) to which to copy it. There must be one MOUNT statement for each volume to be copied, and the FLASHUNIT= value must be unique for each source volume. The online volume identified by VOL= and the target volume identified by FLASHUNIT= must be in the same subsystem and the target must be offline to the operating system. To insure that the target volume is not accidentally brought online, ABR modifies the volume label in a way that FDR can access it but any attempt to bring it online (VARY command or IPL) fails.

FDRABR initiates a full-volume FlashCopy NOCOPY session for each selected online volume and offline target. If a FlashCopy session already exists between those two volumes, it is terminated before the new session is started.

FDRABR can also initiate a FlashCopy COPY session by adding the operand FCOPY=COPY to the FCOPY statement. A FlashCopy COPY session copies all the tracks from the source volume to the offline target volume and may cause excessive overhead on the user’s I/O subsystem. Additionally, the FlashCopy relationship is automatically terminated at the end of the background process, which may cause problems with the Dump Phase if FCOPY=(USE,REL) is specified since the DISBAND and WITHDRAWAL commands generated by the REL operand expect a valid relationship to exist. For these reasons, FCOPY=COPY is not recommended; we suggest that you contact BMC Support for assistance before using it.

FCOPY supports one additional operand. VERIFYVOLSER=YES verifies that each FLASHUNIT target volume currently has the same volume serial as the corresponding online source volume. This is true if the last use of the target was for a FCOPY of this source volume, or if you have used ICKDSF to initialize the target volume. You may need to omit VERIFYVOLSER=YES on the first FCOPY since the VOLSER may not match. VERIFYVOLSER=YES is used to verify that you are not accidentally overlaying a target volume used with another source volume.

In the second phase (“Dump Phase”):

• Add to the DUMP statement one of the operands:

Tells ABR to read the offline copy of the online volume specified in JCL. ABR remembers the device address of the offline device most recently used as a target for a copy of each online volume. At the end of the backup, the FlashCopy session is left active. Specify FCOPY=USE if an Incremental FlashCopy is being retained (FCOPY=INCR).

Same as FCOPY=USE, but at the end of backing up each volume, FDR issues a request to the subsystem to terminate (withdraw) the FlashCopy session. This is recommended.

DSNENQ= and ENQ= are ignored by ABR when dumping point-in-time volume images, since these would prevent access to the online data sets and prevent changes to the online volume's VTOC, not the offline point-in-time image. However, they are honored if you backup other non-point-in-time volumes in the same step.

Since a target volume can hold only one point-in-time image at a time, you must be sure that another FCOPY is not done to the target volume before the second step moves the backup to tape. If you do not, the backup of the previous point-in-time image is lost.

If you have copied a number of volumes, and then executed a DUMP with FCOPY=, and that DUMP step failed for some reason before processing all of the volumes, you can just resubmit the job. ABR bypasses the backup of any volume for which FCOPY was done and the backup has already been moved to tape. However, if you have included in the DUMP step other volumes that are to be backed up normally (for example volumes not capable of FlashCopy), they are backed up again by the restarted backup step.

Multiple systems

Although the FCOPY step and the DUMP step can execute on different operating systems, FDRINSTANT for ABR requires that both systems must be able to access both the source and target volumes and a common ABR catalog. During the FCOPY, ABR updates the online volume, the offline copy, and the ABR catalog. During the DUMP, ABR must read the online volume, and update the offline copy and the ABR catalog.

However, if you only need full-volume backups (no incremental backups), it is possible to do this outside of ABR with PGM=FDR backups; contact BMC Support for guidance.

FDRINSTANT ABR examples

These are examples of FDRINSTANT ABR usage with FlashCopy.

A STEPLIB DD statement may be required in FDRINSTANT steps if you have installed the product in a library other than your standard FDR program library.

If you are also licensed for FDRCRYPT, these backups can be encrypted. SeeFDRCRYPT-Backup-Encryption for details of the job changes required.

ABR full volume backup example

FlashCopy target volumes have been assigned to the online payroll volumes PAYxxx.

Step FULL1 starts FlashCopy sessions for each online volume to its FlashCopy target to create point-in-time images and mark the backups as complete. It creates a new ABR backup generation and updates the online volume with information about each new backup. When this step completes, the point-in-time backup is complete and updates to the online volume can resume. Although only one TAPE1 DD statement is present, the FCOPY process actually processes up to 32 volumes concurrently, to reduce processing time.

The SYSPRINT output of step FULL1 looks something like:

The FDR304 message identifies this as an FCOPY, and the FDR305 message identifies the FlashCopy target unit. It also shows the ABR backup data set name created, and that it was cataloged to the input volume.

Step FULL2 does the actual backups. FCOPY=USE tells ABR to determine if a point-in-time image exists for each volume processed; if so, that image is backed up instead of the online volume. Volumes that have not been captured are processed normally. ENQ=ON (the default) and DSNENQ=USE are ignored when backing up from a point-in-time image. Note that ABR remembers the unit addresses of the offline volumes specified in the FULL1 step; there is no need to specify them here.

The SYSPRINT output for step FULL2 is similar to:

FDR219 messages indicate that a previously created point-in-time image was found for the volume being dumped. FDR305 messages show the actual location of the backup data sets. FDR232 messages indicate that the REL option caused ABR to terminate the FlashCopy session.

In this example, volume PAY004 was not copied. The FDR224 message indicates that there is no point-in-time image of the volume so that a normal ABR backup is done. If you intended to do point-in-time backups all of the volumes in this backup, you must do a FCOPY for PAY004 in the FULL1 step; otherwise the backup from PAY004 is not taken at the same point-in-time as the other volumes. If you have no need to do point-in-time backup on PAY004, you can ignore the message. Therefore, you can include in this ABR step volumes that have no point-in-time requirements; they are backed up normally.

ABR incremental backup example

The FlashCopy target volumes at addresses 01F2 and 01F3 are assigned to online volumes CICS01 and CICS02. Step INCR1 starts a FlashCopy session for each online volume to create a point-in-time image and mark the backup as complete. It creates a new ABR backup cycle and updates the online volume with information about the new backup. As soon as this step completes, the point-in-time backup is complete and updates to the online volume can resume. Note that the RETPD= parameter must be specified the same as in the INCR2 step that follows.

Step INCR2 does the actual backups. FCOPY=(USE,REL) tells ABR to determine if a point-in-time image exists for each volume processed; if so, that image is backed up instead of the online volume. Volumes that have not been captured are processed normally. ENQ=ON (the default) and DSNENQ=USE are ignored when backing up from a point-in-time image. Note that ABR remembers the addresses of the offline targets; there is no need to specify them here.

For examples of messages and other notes, see ABR Full Volume Backup Example 

ABR Incremental FlashCopy DUMP example

The use of Incremental FlashCopy creates a full point-in-time image of the online volume by initially copying all of the tracks to the offline volume. Subsequent Incremental FlashCopy invocations only copy tracks that have been updated since the previous point-in-time image was created. This benefits the installation that requires a full point-in-time image (all tracks copied), as well as the need to have repetitive point-in-time images. An additional benefit is the ability to perform an INSTANT recovery from the offline volume. This is known as Fast Recovery Restore (FRR). Please review the ABR Restore Example in .

Incremental FlashCopy is invoked by adding FCOPY=INCR to the main FCOPY statement as shown below using the previous FCOPY examples:

FCOPY TYPE=FDR Example

FCOPY TYPE=ABR Example

ABR restore example

If it is necessary to do a full-volume restore of one of the volumes involved in the point-in-time backup before the backup is moved to tape, ABR does it automatically. No special parameters or JCL is required. ABR restores from the point-in-time image or from tape automatically. For example, this restores four volumes from the previous full-volume backup example:

Volumes PAY001-003 are restored from the point-in-time images on the target volumes unless they have been moved to tape. Volume PAY004, since it has no point-in-time image, is always restored from tape. However, there are some considerations:

• The point-in-time volume image is always a full-volume image, even if an incremental backup was done. If ABR discovers that the first ABR backup cycle to be restored is a point-in-time image, it simply copies the entire volume back to the target online volume and does not need to read any further backups from tape. Since full-volume restores typically start with the most recent backup of the volume, this provides the fastest recovery.
• But if the most recent ABR backup cycle is on tape, but another lower-numbered cycle is a point-in-time image, ABR bypasses restoring from that image (with a message); any data sets whose most recent backup was on that image may be corrupted or back-level. This could occur if you did a FCOPY to create a cycle but never did a DUMP to move it to tape, and followed that with a regular ABR backup direct to tape. This is not normal and does not occur if your FDRINSTANT procedures are setup correctly.
• If you are restoring to a volume other than the original volume (NVOL= on the SELECT statement) and the target volume is not in the same DASD subsystem as the point-in-time image, ABR does a normal disk-to-disk copy to copy all tracks in the image to that volume.
• If ABR attempts to restore from a point-in-time image (ABR backup data set cataloged to the original volume), but that image no longer exists, ABR bypasses that backup. If it was an incremental backup, it restores the rest of the cycles in that generation. If it was a full-volume backup (cycle 00), the restore fails (you can uncatalog the backup or specify GEN= and CYCLE= to restore from an earlier generation). This can occur if multiple FCOPY operations were done without an intervening DUMP to move the backup to tape. It can also occur at a disaster site if the restored ABR catalog is not consistent with the tapes that were brought off-site (some backup entries still indicate the point-in-time backup).

• If an Incremental FlashCopy image is active and the source online volume is not part of any other relationship, then the full volume can be restored using Fast Recovery Restore (FRR) if both of the volumes are the same device size. Once the FRR process has completed, the offline image is no longer a valid backup and a new FCOPY=INCR is required to create a new incremental point-in-time image. We recommend to follow each FCOPY operation with a matching “Dump to Tape” operation to ensure a backup is retained. FlashCopy FRR is invoked by using the FCOPY=FRR keyword on the main RESTORE statement as shown.

  //REST EXEC PGM=FDRABR,REGION=0M
  //SYSPRINT DD SYSOUT=*
  //SYSIN DD *
  RESTORE TYPE=FDR,DYNTAPE,CONFMESS=NO,ONLINE,
  CPYVOLID=YES,FCOPY=FRR
  SELECT VOL=PAY001
  SELECT VOL=PAY002
  SELECT VOL=PAY003
  /*