Traditional data protection and backup typically rely on a point-in-time copy, which allows restoring data only from when that copy or backup was created. As the name implies, continuous data protection in contrast to traditional data protection and backup has no defined schedule. However, it is usually an asynchronously created copy, which does not necessarily ensure consistent data at any one time. Utilities and other software or middleware-based functions are available to overcome this shortcoming of continuous data backup.

Massive data backups still rely on a point-in-time backup copy that is combined with serialization efforts. For example, database subsystems can temporarily quiesce databases and related data sets, which forces a buffer flush to permanent storage.

The challenge is then to create a backup copy as quickly as possible to make the database data sets available again. Several solutions were developed over time, but the basic and simplest approach is still to create a consistent backup as quickly as possible that also is instantly reusable.

With the DS8000 storage system, the foundation for this simple backup approach is based on the FlashCopy function. The next step was to develop software that intelligently uses FlashCopy to have a fast process to flash or snap a volume or data set.

IBM Fast Replication Backup (FRBACKUP) enables storage administrators to create backup policies for IBM Db2 and IBM IMS databases with minimum affect on applications. Db2 uses this function for Db2 system-level backup and to control the serialization effort that ensures a consistent set of the complete system-level backup, including all Db2 table space and logs. Db2 also maintains its repository, for example, by updating the bootstrap data set (BSDS) to reflect all backup activity.

This chapter describes FRBACKUP and other backup solutions that use FlashCopy with Db2 and IMS, adding to the list of synergy items between IBM Z server and DS8000 storage systems.

This chapter includes the following topics:

FRBACKUP is a storage-based solution that uses storage software components of the z/OS Data Facility Storage Management Subsystem (DFSMS) with its components Data Facility Storage Management Subsystem Data Facility Product (DSSMSdfp), Data Facility Storage Management Subsystem Hierarchical Storage Manager (DFSMShsm), and Data Facility Storage Management Subsystem Data Set Services (DFSMSdss). These components can interact and use DS8000 Copy Services functions, and here in particular, DS8000 FlashCopy and its various characteristics.

All of the involved storage components from a hardware perspective and z/OS DFSMS software that is involved are shown in Figure 3-1.

The configuration shows all important components from a storage perspective. Although the configuration might appear to be a complex solution, it is simple rather than complex. It is logically divided into two parts by a horizontal bar (showing FRBACKUP).

For more information, see DFSMShsm Fast Replication Technical Guide, SG24-7069.

Different types of Storage Groups (SGs) are used to support FRBACKUP input and output. On the input site to FRBACKUP is a copy pool. Another SG type, the Copy Pool Backup Storage Group (CPBSG), supports FRBACKUP on the output site of FRBACKUP.

The Storage Management Subsystem (SMS) construct of the Copy Pool is shown in Figure 3-2. The conventional z/OS volumes are grouped in conventional SMS pool SGs. Two DS8000 storage systems and SMS with two SGs that contain all the relevant logical volumes are used.

The example that is shown in Figure 3-2 might represent a Db2 environment with log volumes and database volumes. The log volumes are grouped in SG SG1. All database volumes are grouped in SG SG2.

Copy Pool 1 incorporates only a single SMS SG (SG SG1). A Copy Pool can contain as many as 256 SMS pool SGs, and all of these SGs are then processed collectively during FRBACKUP processing. In this simple configuration, Copy Pool 2 is defined with another single SG2 SG. Copy Pools serve as input to the FRBACKUP process.

For more information about defining Copy Pools, see z/OS DFSMSdfp Storage Administration Version 2 Release 3, SC23-6860-30 or IBM Knowledge Center.

A second construct is another SMS SG type. The CPBSG is a logical bracket around candidate target FlashCopy volumes. All volumes within a CPBSG are reserved for DFSMShsm FRBACKUP requests and for DFSMShsm use only.

CPBSG is associated with Copy Pools only. When preparing for an FRBACKUP process, DFSMShsm interfaces with SMS to assign to each FlashCopy source volume from the Copy Pool a corresponding FlashCopy target volume in the CPBSG. Therefore, you must have enough eligible FlashCopy target volumes available to map all volumes from a Copy Pool to the CPBSG.

As shown in Figure 3-3, the DS8000 storage systems need enough disk space for FlashCopy target volumes to accommodate all FlashCopy source volumes from the Copy Pool that originates from the same DS8000 storage system. All volumes in Copy Pool 1 and in Copy Pool 2 from DS8000_#1 need at least another FlashCopy target volume in the same DS8000_#1 within a corresponding CPBSG when only one copy is required. FRBACKUP supports up to 85 copies.

When you define a Copy Pool, consider keeping backup versions on tape. DFSMShsm automatic dump processing can create these tape copies.

For more information, see the following resources at IBM Knowledge Center:

Combining Copy Pool and Copy Pool Backup Storage Group is required. A 1:1 mapping of two Copy Pools into two corresponding CPBSGs is shown in Figure 3-4.

To keep the example simple, two Copy Pools are defined in Figure 3-4, each with its own CPBSG. In reality, more flexibility is available, if needed. For example, an SMS pool SG might need to belong to more than one Copy Pool, or a CPBSG might need to be shared by multiple Copy Pools.

The DFSMShsm frbackup command starts the process to flash all volumes within the relevant Copy Pool to assign dynamically FlashCopy target volumes in the CPBSG. Figure 3-5 shows this process, which can be started only through the DFSMShsm FRBACKUP interface.

DFSMShsm interfaces with SMS to select FlashCopy target volumes for each source volume from the Copy Pool. To shorten this FlashCopy volume mapping process, the frbackup command can be issued with the prepare parameter.

The frbackup command that is issued through TSO is shown in Example 3-1. The prepare parameter triggers DFSMShsm to select a FlashCopy target volume for each Copy Pool-based volume and preserves this mapping until the actual FRBACKUP process issues all the flash copies.

Another DFSMShsm frbackup command that is issued again through TSO and performs the actual FlashCopy operations is shown in Example 3-2.

The example that is shown in Figure 3-1 on page 32 implies two versions for each FRBACKUP process with six FlashCopy target volumes in each DS8000 storage system for Copy Pool 2 and two FlashCopy target volumes in each DS8000 storage system for Copy Pool 1.

The software-based interaction within z/OS is shown in Figure 3-6. DFSMShsm has the leading role in managing the complete FRBACKUP process and communicates with the key address spaces, which are required to provide support to create successfully FlashCopy based volume copies.

The interaction that is shown in Figure 3-6 shows a Db2 based environment with logging volumes and table spaces within a single Copy Pool and its related CPBSG. Because FRBACKUP has a counterpart, Fast Replication Recover (FRRECOV), this FRBACKUP volume set in the CPBSG allows for a recovery on an individual table space (data set level). This capability requires getting all related catalog information during the FRBACKUP process.

To achieve a highly parallel process, DFSMShsm starts several DFSMSdss instances because DFSMSdss is the actual interface to FlashCopy in the DS8000 storage system. For more information, see DFSMShsm Fast Replication Technical Guide, SG24-7069.

As shown in Figure 3-6 on page 37, FRBACKUP is another example of the close synergy between z/OS and DS8000 Copy Services.

The FlashCopy (point-in-time copy) function in the DS8000 storage system has an extraordinary synergy with IBM Z storage management, which is delivered through a few powerful interfaces. FlashCopy opens many possibilities and several interesting use cases for backups of your entire system. It enhances testing capabilities by quickly cloning environments without application disruption. It also increases the availability of Db2 and IMS utilities.

The following interfaces can be used to configure and control FlashCopy process for z/OS users:

This section describes how Db2 and IMS databases use the DS8000 FlashCopy function.

IBM DB2® for z/OS utilities frequently are enhanced to use more of the DS8000 FlashCopy function. New Db2 versions included enhancements to use Db2, DS8000 storage systems, and z/OS synergy, as listed in Table 3-1.

The Db2 BACKUP SYSTEM utility is used to take a fast and minimally disruptive system-level backup. It backs up the entire data sharing group with all Db2 catalog and application data. The advantage of this utility is that you do not need to suspend or quiesce the Db2 logs and hold off the write I/Os. During the backup process, all of the update activities are available. However, you cannot modify several items, for example, you cannot create, delete, and extend a data set.

The BACKUP SYSTEM calls the DFSMShsm frbackup command (as described in 3.1, “FRBACKUP” on page 32), which is converted into DFSMSdss copy commands that start FlashCopy at a volume level.

The Db2 BACKUP SYSTEM supports incremental FlashCopy. The ESTABLISH FCINCREMENTAL keyword is used for that purpose. This keyword establishes the persistent FlashCopy relationship, and you use it only the first time you start the BACKUP SYSTEM utility.

The next time that you start the BACKUP SYSTEM utility, it takes an incremental FlashCopy from the physical background copy. This persistent incremental FlashCopy relationship can be stopped by using BACKUP SYSTEM END FCINCREMENTAL parameter.

After the BACKUP SYSTEM completes, the restore is done by using the RESTORE SYSTEM utility, which can restore a complete system. Similar to the BACKUP SYSTEM utility, RESTORE SYSTEM calls the DFSMShsm FRRECOV command, which is converted into DFSMSdss copy commands that start FlashCopy in the background.

Another possibility is to restore an individual Db2 object (table space or index) from the full system backup. Unlike the full BACKUP SYSTEM and RESTORE SYSTEM that use the FlashCopy on the volume level, the data-set-level FlashCopy is used when the single Db2 object is recovered. The SYSTEM_LEVEL_BACKUPS parameter should be set to YES (default is NO).

DFSMShsm is used in the background to extract the data set from the volume level FlashCopy that is taken with BACKUP SYSTEM.

Db2 features an option to start data-set-level FlashCopy to create image copies. Although the Image Copy utility supports image copies, data-set-level FlashCopy can be used by any Db2 utility that creates an inline image copy, such as a Db2 reorg, load, rebuild index, and reorg index.

By using FlashCopy in the background, the IBM Z CPU is offloaded to the DS8000 FlashCopy process. In addition, the Image Copy utility is completed when the FlashCopy relationship is established.

FlashCopy image copy can be taken concurrently with share-level reference Image Copies, and without any effect on the applications.

Unlike the BACKUP SYSTEM, FlashCopy image copy starts DFSMSdss directly. Because DFSMShsm is not involved, you do not need to plan your data placement (for example, Integrated Catalog Facility (ICF) catalogs). The only requirement is that all Db2 volumes must be SMS-managed.

When the FlashCopy image copy is created, it is available for restoring. When the recover utility restores the FlashCopy image copy object, it starts FlashCopy through DFSMSdss.

Although the Check Index, Check Data, and Check LOB utilities are not used frequently, they are some of the most important utilities regarding data corruption analysis. These utilities can help you find the level of corruption and the best recovery processes.

Here, the FlashCopy synergy with these Check utilities plays an important role. In the situation where you suspect data corruption, a prompt investigation is critical. Running the Check utilities while the application is running can save enormous amounts of time.

FlashCopy provides an option to run a Check utility nondisruptively with share-level change (by using the SHRLEVEL CHANGE parameter) included. The use of this option creates a shadow data set of data, indexes, and large objects (LOBs) that can be checked by the utility that uses the DSFSMdss copy command (FlashCopy).

When the FlashCopy is established (several seconds), the Check utility starts using the shadow data set (FlashCopy target data set). The shadow data set is in read-only mode only while the FlashCopy relationship is being established. After the DFSMSdss confirms that the FlashCopy is established, full read and write access to the data set is restored.

Therefore, without FlashCopy and the Check utility with share-level access, the shadow data set is created with the standard I/O by using the IBM Z resources rather than DS8000 storage system. This process can be disruptive for the application. To avoid this situation, a suggestion is to update the ZPARM FlashCopy fastreplication keyword to REQUIRED rather than PREFFERED, which is default value in Db2 V10 and later. This parameter ensures that FlashCopy is used every time. If problems occur while FlashCopy is started, the Check utility fails, which is a better outcome than any application outage.

Various IMS utilities, as is the case with Db2, use DFSMSdss to start the DS8000 FlashCopy function. This section provides information about IMS High-Performance Image Copy (IMS HP IC), which is used for IMS backup and restore.

IMS HP IC provides fast back up and recovery of database data. Although it includes many services, we focus on Advanced Image Copy Services, which allow IMS HP IC to produce faster image copies and increase availability time for IMS databases.

Advanced Image Copy Services use the DFSMSdss cross-memory API, ADRXMAIA, to process the DFSMSdss DUMP and COPY commands. These commands allow IMS HP IC to use the DS8000 FlashCopy advanced point-in-time copy function.

The FlashCopy and IMS synergy allows you to back up a database or any collection of data at a point in time and with minimum downtime for the database. The database is unavailable only long enough for DFSMSdss to initialize a FlashCopy relationship for the data (data-set-level FlashCopy), which is a small fraction of the time that is required for a complete backup. The copy that is made does not include any update activity. When the FlashCopy relationship is established, DFSMSdss releases all the serialization that it holds on the data, informs the Advanced Image Copy services about it so that update activity can resume, and begins reading the data.

The following Advanced Image Copy Services types are shown in Figure 3-7:

The COPY process is used to create Image Copy Data Set (ICDS) quickly and to recover the database faster. This process is possible because FlashCopy is started as a background task.

Similar to the COPY process, FDUMP can be used when you must create a quick shadow of ICDS and dump it to tape.

The DUMP process does not use FlashCopy, and it is limited only to the Concurrent Copy function.

For more information about IMS and High-Performance Image Copy, see IBM IMS High Performance Image Copy for z/OS, Version 4 Release 2, User’s Guide, SC19-2756.