FDRINSTANT for EMC TimeFinder Consistent Backup Support

FDRINSTANT for FDRABR supports Consistent Backup of DASD by using TimeFinder/CG (Consistency Group support):

• With TimeFinder/Mirror, Consistent Split of BCVs is supported.
• With TimeFinder/Clone and TimeFinder/Snap, Consistent Snap is supported.
• You need to install TimeFinder/CG (Consistency Group) in addition to the other TimeFinder options to get this support; consult your EMC marketing team for details.

Consistent Backup allows you to split a number of BCVs or Snap a number of volumes at the same point-in-time, in other words, at the same point of I/O consistency. I/O consistency means that all the backups of the volumes are at the same point in I/O processing, and there is no possibility that some of the volumes will 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 backups, the splits or snaps 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 TimeFinder/CG prevents dependent I/O from being issued by the application during the SNAP or SPLIT process, thus ensuring the integrity and consistency of the data on the backups. 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 split. 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 should 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 split 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 split does not insure that data sets, VTOCs and VVDSs are error-free if you must restore a backup created after a consistent split (or even a normal split). If a SNAP or SPLIT 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 will 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 improve this exposure.

Unless you take all possible steps to quiesce update activity on a volume before it is split (with regular or consistent split), 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
• PROCLIB data sets
• ABR user catalog
• ABR load library
• Link list (LNKLST)
• IPL volume
• SMF data set
• Coupling Facility data sets
• Paging data sets
• Scheduling system data sets
• SYSOUT intercept data sets
• Data used by other products that communicate between systems such as cross-system enqueue products

Using FDRINSTANT Consistent Backup on such volumes may result in interlocks and system failures. FDRINSTANT holds a hardware RESERVE on all volumes involved in the SNAP or SPLIT, and uses EMC hardware to inhibit I/Os to the volumes, but it may need to invoke system services or cause paging which will require normal access to such data sets. Therefore, if they are involved in the Consistent Backup, the results can be serious or fatal to your system.

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 SNAP in earlier parts of this chapter. However, the main statement in the SNAP step specifies CONSNAP instead of SNAP as shown in the example below.

The MOUNT statements in the CONSNAP step must identify all of the volumes that must be SNAPed at the same consistent point-in-time, even if they are in multiple EMC DASD subsystems. We recommend that you provide one MOUNT per volume involved, including the SNAPUNIT= operand on each MOUNT so that ABR knows the UCB device number of the target associated with each online volume; this will speed up processing.

The CONSNAP step operates in two phases:

• SNAP 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 RESERVEs or enqueues are obtained on every volume, FDRABR invokes an EMC Consistent hardware assist on each volume, which inhibits all I/O to the DASD from all systems. Finally, it issues the Consistent Snap request for all volumes (one to each EMC subsystem involved) and releases the Consistent Assist, allowing I/O to resume. However, the RESERVE or enqueue is still held. All the volumes specified on MOUNT statements in the step are consistently SNAPed at the same time.
• ABR 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 CONSNAP 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 CONSNAP step must be followed by a regular ABR DUMP step, specifying SNAP= on the DUMP statement, as shown in the examples below and in earlier in this chapter.

Additional operands

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

These operands can be added to the CONSNAP statement:

nn

Specifies the number of volumes that are processed concurrently during the ABR processing phase. 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 step are snapped 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 tries to acquire them again (see “RESVTIMEOUT=” in Section 25.6). 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 operation.

Default: 10.

Additional MOUNT operands

This operand can be added to any MOUNT statement in the CONSNAP 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.

CONSNAP example

Here is an example showing CONSNAP. This shows a full-volume ABR backup, but it can also be used with ABR incremental backups (TYPE=ABR, AUTO, or DSF). This 3-step procedure is used when it is desired that the SNAPed volumes remain on the online volumes for a period of time before being dumped to tape.

Step DUMP1 does the actual full-volume backups. SNAP=USE tells ABR to determine if a snapped point-in-time image exists for each volume processed; if so, that image is backed up instead of the online volume. ABR remembers the addresses of the BCVs snapped in step SNAP1.

Since RET was not specified on the SNAP= operand, the volumes need to be RE-ESTABLISHed manually. A FDRDSF job can perform the RE-ESTABLISH. Up to 39 DASD volumes can be specified in a single step using this procedure. If more than 39 DASD volumes are needed, multiple steps can be specified.