FDRINSTANT for FlashCopy Consistent Backup Support

FDRINSTANT for FDRABR and FDRFLASH support Consistent Backup of DASD volumes by using FlashCopy Consistency Group in control units that support FlashCopy.

Consistent Backup allows you to flash a number of volumes preserving an I/O Consistent point-in-time copy. In other words, at the same point of I/O consistency. I/O consistency means that all the backups of the flashed volumes are at the same point in I/O processing, and there is no possibility that some of the volumes contain the results of I/Os issued after that point.

I/O consistency is particularly important to applications that execute dependent write I/Os. Dependent writes are issued by the application in a particular order and the next write in the sequence is not done until the previous write has successfully completed. Many applications, and in particular database management systems (DBMSs such as DB2), use dependent writes to ensure data integrity in the event of a hardware or software failure.

To execute a database update, the DBMS may write information about the update to the log data set, then it does the actual database update (one or more I/Os), then it updates the log to indicate that the database update was successfully done (“committed”). If the DBMS is restarted after a failure, it can tell which database updates were completed and which were not (“in-flight”) and do the proper recovery.

During a normal backup, if the DBMS is still active, the volumes may not be at a consistent point-in-time. For normal FDRABR backups, the volumes may be processed many minutes apart. Even with FDRINSTANT for FDRABR or FDRFLASH backups, the flashes of the volumes may be separated by seconds. If these backups must be restored, the DBMS may not be able to restart the databases because the logs and databases are not consistent. The usual means of addressing this problem is to suspend updates to the database during the backup process (in some releases of DB2, this is done with the LOG SUSPEND command).

FDRABR support for FlashCopy Consistency Group maintains I/O consistency by the application during the flash process, thus ensuring the integrity and consistency of the data on the flashed volumes. This results in a copy of the data that is restartable after a restore, even though the DBMS may have been updating the databases during the flash. There is no need to suspend updates to the database during the Consistent Backup operation.

When to use Consistent Backup

Consistent Backup is most appropriate when the volumes involved contain only the data sets that are used by a single DBMS or database application. Be sure to include volumes containing the log files used by that DBMS or application.

For volumes containing other types of data sets, Consistent Backup may or may not be appropriate. If the data sets or applications that use them are tolerant of system failures and provide appropriate recovery when restarted and related data sets are spread across multiple volumes, then you may be able to use Consistent Backup on those volumes without quiescing the application. However, this recovery needs to be tested to be sure that it works properly.

Although Consistent Backup insures I/O consistency between volumes, it does not insure that a sequence of I/Os issued to a given volume is complete. For example, if a VSAM file is undergoing a CA split, which requires multiple I/Os to the cluster and several I/Os to the VVDS, the flash may still capture an image of the volume at a point in the middle of those I/Os, which may make the cluster unusable when restored.

Most data sets and most applications do not provide the dependent writes and recovery provided by database systems, so consistent backup does not insure that data sets, VTOCs and VVDSs are error-free if you must restore a backup created after a consistent backup (or even a normal flash). If a flash occurs in the middle of a sequence of update I/Os, data sets may contain improper formatting or I/O errors, and the VTOC or VVDS may have partially completed updates that cause errors or failures. Of course, these sorts of problems may also occur if you do a normal backup of an online volume while it is being updated; consistent backup does not eliminate this exposure.

Unless you take all possible steps to quiesce update activity on a volume before it is flashed (with regular or Consistency Group flash), the possibility exists that the data sets or volume may not be usable when restored, unless the data or application is designed to tolerate such partially completed I/O (as described above for DBMS).

Do not use Consistent Backup on volumes containing system data, such as:

• Catalogs
• Tape management data
• Security data
• JES2/JES3 spool or checkpoint data
• Coupling Facility data sets
• Paging data sets
• Data used by other products that communicate between systems such as cross-system enqueue products

FDRINSTANT Consistent Backup is performed using Extended Long Busy (ELB) that may result in interlocks and system failures on such volumes. Therefore, if they are involved in the Consistent Backup, the results can be serious or fatal to your system.

Restrictions and Considerations

• Only one FlashCopy Consistency Group operation can be performed at a time, since the FlashCopy microcode does not support concurrent operations. You must insure that the Consistent Backup (CONFLASH) step has finished before another is allowed to start.
• CONFLASH issues a FlashCopy establish to each volume selected with the “freeze” option; this adds the volume to the subsystem-wide consistency group and suspends all I/O to the volume. Once all volumes have been established, a “thaw” request is issued to re-enable I/O to all volumes at once.

Using Consistent Backup with ABR

In order to use Consistent Backup with FDRABR, you use essentially the same FDRABR procedures that are documented for normal FCOPY in FlashCopy-for-ABR. However, the main statement in the flash step specifies:

Instead of FCOPY as the operation name.

The MOUNT statements in the CONFCOPY step must identify all of the volumes that must be flashed at the same I/O consistent point-in-time. You must provide one MOUNT per volume involved, including the FLASHUNIT= operand on each MOUNT.

The CONFCOPY process operates in two phases:

1. Instant Phase – By default, FDRABR first obtains a SYSVTOC RESERVE on each volume specified; this is to inhibit I/O to the volume from other systems and to insure against partially completed VTOC and VTOCIX updates from all systems. However, if SYSVTOC RESERVEs are being suppressed (for example, by the GRS Reserve Conversion RNL), FDRABR does a SYSVTOC enqueue instead. Once the SYSVTOC has been serialized, the Consistency Group Flash request with “freeze” option to suspend I/O to the source volumes specified in this Consistency Group request. After all volumes have been processed, they are “thaw-ed” to allow I/O to resume.

   Important

   If multiple CONFCOPY FLASH processes are being run on a single Logical Subsystem, they must be run serially.

2. ABR Dump Phase – At this point, ABR begins its normal processing of each volume, identifying the data sets on each volume that are backed up (depending on whether this is a full-volume or incremental backup) and marking them in the VTOC of the online volume. As it completes each volume, it releases the SYSVTOC RESERVE or enqueue. This usually takes only a few seconds per volume, although it may take longer on volumes with especially large VTOCs or VVDSs or a large number of data sets. ABR uses an internal sub-task for each volume, and CONFCOPY has been enhanced to use up to 32 sub-tasks to do this phase of processing on up to 32 volumes at a time.

The CONFCOPY Instant Phase must be followed by a regular ABR Dump Phase, specifying FCOPY= on the DUMP statement, as shown in the examples below and in FlashCopy-for-ABR.

Additional CONFCOPY operands

There are some additional operands that can optionally be specified in a CONFCOPY step. None of them are required and you rarely need to use them unless instructed to do so by BMC Support.

These operands can be added to the CONFCOPY statement:

nn

Specifies the number of volumes that are processed concurrently during the ABR processing phase of CONFCOPY. This does not affect the total number of volumes that may be involved in the Consistent Backup; all volumes specified on the MOUNT statements in the CONFCOPY step are flashed at the same time.

Default: 32 (and the maximum).

RESVTIMEOUT=

nn

This specifies the time (in minutes) that FDRINSTANT for FDRABR waits to acquire the SYSVTOC reserve on each volume involved in the Consistent Backup. If it cannot acquire the reserve within this time, it releases all reserves that it has already acquired on other volumes and starts again to acquire all the reserves. This is to avoid interlocks with other systems because of the hardware reserves.

Default: 1 minute.

nn

This is the maximum number of times that FDRINSTANT for FDRABR releases the RESERVEs and try to acquire them again (see RESVTIMEOUT). If it cannot acquire the RESERVE on every volume in the Consistent Backup (except those for which RESENQ=NONE was specified) with this number of attempts, it fails the CONFCOPY operation.

Default: 10.

Additional MOUNT operands

This operand can be added to any MOUNT statement in the CONFCOPY step:

This suppresses the SYSVTOC reserve and enqueue for the volumes on that MOUNT. However, if the reserve or enqueue is suppressed, then FDRINSTANT for FDRABR cannot protect against partially completed VTOC updates done by other systems, which may result in corrupted VTOCs when the backup is restored. RESENQ=NONE is intended for use for volumes where there is little or no update activity to the VTOC and other data sets, when a reserve could result in errors or interlocks. Do not use this operand unless you understand its implications; contact BMC Support for guidance.

CONFCOPY for ABR example

Here is an example similar to those in FlashCopy-for-ABR, modified to show CONFCOPY. This shows a full-volume ABR backup, but it can also be used with ABR incremental backups (TYPE=ABR, AUTO, or DSF).

Step FULL1 flashes the specified volumes to create the I/O consistent point-in-time images and mark the backups as complete. It creates a new ABR backup generation and updates the online volumes with information about the new backups. Although all the volumes specified by the MOUNT statements are flashed in one consistent flash operation in the Instant Phase, the ABR processing phase does 32 volumes concurrently, in order to reduce the elapsed time of the CONFCOPY step. The elapsed time of the step depends on the size of the VTOC and VVDS and the number of data sets on the volume. As soon as this step completes, the point-in-time backup is complete. ENQERR=NO is specified because the data sets to be dumped (for example, database files) are likely to be allocated at the time of the CONFCOPY.

Step FULL2 does the actual full-volume backups. FCOPY=(USE,REL) tells ABR to determine if a flashed point-in-time image exists for each volume processed; if so, that image is backed up instead of the online volume. ABR remembers the target addresses of the volumes flashed in step FULL1. Each FlashCopy session is released as soon as its backup is complete.

CONFCOPY for FDR example

Here is an example of using program FDRFLASH with FDRusing CONFCOPY.