Do you want to learn why Database backups are different from file backups? Click HERE to find out.
Do you want to learn why
are different from file backups?
Click HERE to find out.
FDRinstant uses the 'instant copy' facility which all the major z/OS disk vendors provide. I've worked with an implementation based on Flashcopy from IBM, but the same principles apply to EMC Timefinder, Oracle StorageTek's Snapshot copy and HDS Shadowimage. The principle behind all these is that FDRinstant will create an image of a disk using the API provided by the hardware. That image is essentially another volume, with its own UCB. Depending on the implementation, this may be a real volume with all the data copied, it may be a virtual volume created by pointers, or it may be a mixture of the two. The off-line volume is then marked as a valid backup, and is recorded in the FDRABR catalog. The online volume identified by VOL= and the target volume identified by FLASHUNIT= may need to be in the same subsystem, depending on the hardware, and the target must be offline to z/OS.
FDRINSTANT also supports Space Efficient FlashCopy. If you have it installed then FDRINSTANT will automatically detect those DASD units that are using Space Efficient flash, and use it for the FlashCopy relationship. Incidentally, the FlashCopy target volumes are not eligible for Parallel Access Volumes as they are only accessed by FDR.
When FDRinstant is used for dump processing, it uses the NOCOPY option of FlashCopy, as the copied data is only needed for a short amount of time until the dump to tape completes. In this case, only tracks being updated are copied to the target to retain the point-in-time image. Once the task completes, the FlashCopy relationship is withdrawn and that target volume is no longer valid.
If you need to retain the flashcopy volumes beyond the backup processing, then this is possible by adding the operand FCOPY=COPY to the FCOPY statement. This is not recommended by Innovation as a COPY session copies all the tracks from the source volume to the offline target volume and this may cause excessive overhead on your I/O subsystem. Also, when the COPY process completes the FlashCopy relationship is automatically terminated. If this happens before the dumps run and they use FCOPY=(USE,REL), then this expects to find a valid FlashCopy relationship and errors will happen if it does not exist.
When a volume is in use by FDRinstant, the volume label is marked by FDR so it cannot be varied online. This prevents duplicate volume messages, and means the wrong volume cannot be brought on-line at IPL time, as that could be disastrous. You should still define these volumes as being offline in your IO configuration to prevent error messages. There is also no point in defining PAV aliases for these volumes as they will only be used by FDR.
Say you wish to backup a volume VOL001, with UCB B020. You would need an empty disk with the same capacity or more, and if you are using Flashcopy, it may need to be in the same subsystem, depending on the hardware. Say you have a free disk at B035. You would then code FDRinstant statements, invoking PGM=FDRABR, like
This would create an instant backup of all the data on VOL001, on the disk with UCB B035. TYPE=FDR means it will be a full backup. The backup will be recorded in the FDRABR catalog, with a volser of VOL001. The job will update all the archive bits in the VTOC on the online source disk, VOL001, and also update the special FDRABR bits in the F1DSCB in the VTOC entries for every dataset. The process takes a few seconds. Once the job completes, you should see a message
FDR231 FDRFLASH COMPLETED SUCCESSFULLY - VOL=VOL001 TO FLASHUNIT=B035
At this point, you can restore data from the off-line disk using standard FDRABR recovery techniques. Most people want to keep more than one backup for recovery purposes, and few can afford to keep all those backups on disk, so the next stage is to move the data off disk to tape. To do this, the following FDRABR job is required.
This tells the ABR dump to use an existing flashcopy dump, and then release the flashcopy relationship when it is complete. In the joblog, you would see statements like
FDR219 FDR VOL=VOL001 IS BEING DUMPED FROM OFFLINE UNIT=B035
FDR232 FDRINST RELEASED OFFLINE FLASHUNT=B035
FDR232 FDRINST DISBANDED PATHS FROM OFFLINE UNIT=B035
The job then updates the FDRABR catalog to point to the tape as a backup, and not the flashcopy disk.
The next pageset provides tips on how to make this work.
The recovery process uses standard FDRABR restore JCL, no special parameters are needed if the backup has not been moved to tape and is still on disk. If you are recovering an entire volume and the backup is still on disk then all the data will be retrieved from the disk copy, even if the current backup is an incremental. This is because all the data is copied by the flashcopy process, so there is no need to build an image of the disk up from incrementals and the latest full backup.
The following example outlines how FDRINSTANT could be used with EMC TimeFinder/Snap or TimeFinder/Clone to run a full volume backup. The JCL just contains one DD statement, but in fact the SNAP will process up to 10 volumes concurrently. The RTC=YES parameter means that most of the FDR buffers are moved above the 16MB line to allow more concurrent backups to run. If you wanted to run this as a consistent backup using a TimeFinder/Consistency Group, just replace the SNAP statement with by CONSNAP. The SNAPUNITs in the JCL are addresses of virtual disks.
Step1 creates the point in time images, step 2 uses FDRABR to copy those images off to tape
//STEP1 EXEC PGM=FDRABR,REGION=0M
//SYSPRINT DD SYSOUT=*
//SYSPRIN1 DD SYSOUT=*
//SYSPRIN2 DD SYSOUT=*
//TAPE1 DD DUMMY
//SYSIN DD *
//STEP2 EXEC PGM=FDRABR,REGION=0M
//TAPE1 DD DSN=FDRABR,LASTAPE,ABR1,UNIT=CART,DISP=(MOD,KEEP)
//TAPE2 DD DSN=FDRABR,LASTAPE,ABR2,UNIT=CART,DISP=(MOD,KEEP)
//SYSIN DD *
It takes a small, but finite length of time to establish a FlashCopy of a disk. If you are flashing a large number of disks, this may take a few minutes to complete, so some disks will be frozen at a different point of time to others. This is a real problem for applications that need all their data to be frozen at a specific and consistent point in time.
An example would be DB2 databases. First, DB2 writes a record to a log file to say that an Update is about to happen, then it does the update to disk and finally it updates the logfile again to say the update completed successfully. This is called a Dependent Write sequence as all three IO sequences must happen in the correct order, so that if an error happens, DB2 knows exactly where it was and can take appropriate corrective action.
To ensure that the IOs are consistent, FDRinstant can freeze the IO over a group of disks using the Consistency Group facility of Flashcopy, provided all the disks in the group are hosted in control units that support FlashCopy. This maintains I/O consistency by the application during the flash process, thus ensuring the integrity and consistency of the data on the flashed volumes.
Without consistency groups, you need to suspend updates to the database during the backup process, for example, by using the DB2 LOG SUSPEND command.
All IBM disk subsystems now use Flashcopy version 2, so FDRinstant may be invoked by FDRCOPY. If you copy a file and both source and target disks are in the same disk subsystem, FDRCOPY will invoke Flashcopy and the copy will appear to be almost instantaneous. This happens automatically, you do not need to specify special parameters in your copy job. The initial target dataset is defined by using pointers to the source file. The actual data copying process is carried out in the background. If you try to access a track that has not been copied yet, you will read the data from the source files via the pointer. The Flashcopy section explains how this works. In this case, FDRinstant uses the COPY option of FlashCopy by default, as the copied data must be permanent. All of the data tracks are copied to the target.
An alternative is to create a frozen copy of a set of files at a consistent point in time, then copy them with FDRCOPY. To do this, you need to reserve a set of offline volumes, then run the FDRFLASH program with the FCOPY parameter as shown below.
//COPYVOLS EXEC PGM=FDRFLASH
//SYSPRINT DD SYSOUT=*
//TAPE1 DD DUMMY
//SYSIN DD *
You use FDRFLASH for FDR, FDRDSF, or FDRCOPY processing and FDRABR for ABR processing.
If you run FDRFLASH to copy a volume, and a previous volume copy is active between the same two volumes, FDRFLASH will withdraw the previous FlashCopy relationship and start a new one. This means that you must make sure that your copying process from one FDRFLASH is complete before starting a new one.
FDRCOPY MOVE operations from a point-in-time copy are not supported by FDRINSTANT since it deletes the input data set.