Repostor Backups

Do you want to learn why Database backups are different from file backups? Click HERE to find out.

Do you want to learn why
Database backups
are different from file backups?
Click HERE to find out.

FDRABR Restores

Recovering an Entire Volume

It is easy to recover a full volume using FDRABR. The JCL you need is

//STEP1 EXEC PGM=FDRABR
//DISK1    DD UNIT=3390,DISP=OLD,VOL=SER=oldvol
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSIN    DD *
   RESTORE   TYPE=FDR,CONFMESS=YES,DYNTAPE
   SELECT   VOL=restvol,GEN=CURRENT

The oldvol in the DISK DD statement is the volser of the volume that you are going to overwrite. This must be offline to all systems except the one you are restoring from.
RESTORE TYPE=FDR means this is a full volume restore.
CONFMESS=YES puts a message on the system console, which must be replied to, to confirm that this restore can happen. It is not essential, but gives you an extra safety check. If you are recovering a lot of volumes after a disaster, you may want to change this to CONFMESS=NO
DYNTAPE means that ABR will dynamically allocate all the tapes it needs, you do not need to supply TAPE DD statements.
SELECT VOL=restvol is the volser of the disk you want to restore. This can be the same as the oldvol above, of course.
GEN=CURRENT means rebuild the disk from the most recent backups

ABR uses the newest incremental and restores all the files that were backed up on that incremental, including the VTOC. It then reads back through the incrementals to the full backup, and restores the newest version of each dataset, until it has rebuilt the disk exactly as it looked at the last incremental backup.
Contrast this with DFDSS, where you restore the latest full backup, then apply the incrementals yourself, in the correct order. You will end up recovering some files several times, and the end result will not reflect the latest state of the disk, as some files which were deleted will now be present.

If you are going to recover a lot of volumes with FDRABR, maybe in a disaster recovery situation, then you should consider purchasing FDRDRP. Every modern high-capacity tape will typically hold several volume dumps and if you use the TYPE=AUTO option on your backups, then these dupms may be a mix of full and incemental backups. If you recover the volumes using traditional FDRABR, then it will mount and dismount each volume every time it needs to access a dump, and this will be very time consuming. FDRDRP will restore multiple disk volumes that have been backed up onto high-capacity tapes in one pass of each tape. InnovationDP claims that this will slash recovery times by up to 80%.

For the ABR reconstruction to work, its essential that the files are not moved around on the disk. If you use IBM's DEFRAG to consolidate free space, then ABR recoveries from incrementals will not work. The answer is to either use Innovation's COMPAKTOR product to consolidate free space, or to force a full disk backup after a DEFRAG.

ABR DATA SET RESTORES

Dataset restores are usually very simple too. Sample JCL is

//STEP1 EXEC PGM=FDRABR
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSIN DD *
  RESTORE  TYPE=ABR,DYNTAPE,DSNENQ=USE
  SELECT DSN=dataset.to.be.restored

RESTORE TYPE=ABR means that this is a dataset restore
DSNENQ=USE means check to see if the file is in use before overwriting it. You can use DSNENQ=NONE, in which case ABR will just ignore file-in-use indicators, but this is rarely a good idea as you do not want to overwrite a file which is in use.
SELECT DSN= picks out the file you want. You can have several select statements in one job. ABR will use the ABR catalog locate mechanism is discussed in the previous page, to find the backups of the datasets, and will mount tapes as required. This restore will overwrite the original, if it exists.

ABR has lots of extra recovery options, some of the ones I have found to be useful are

RESTORE options

SELECT options

VSAM restores

VSAM dataset recovery can be a bit more complicated, but will usually work as long as you remember a few simple rules

Simple VSAM restores

Always select the CLUSTER name for the file you want restored, do not select the individual data and index components

RESTORE  TYPE=ABR,DYNTAPE,DSNENQ=USE
SELECT   DSN=vsam.cluster.name

Restoring a VSAM file to a new name

Use the NEWI parameter to give the cluster a new name.

RESTORE  TYPE=ABR,DYNTAPE,DSNENQ=USE
SELECT   DSN=vsam.cluster.name,
         NEWI=new.cluster.name

If your original VSAM cluster had three levels and you specify a new two level name then only the first two levels will be changed

For example a restore of DWP.BILLING.RUN1 using parameters

SELECT DSN=DWP.BILLING.RUN1, NEWI=DAT.TESTING

Would restore a file called DAT.TESTING.RUN1

Multi-volume VSAM file restores

Recovery of large, multi-volume VSAM files can sometimes be problematical. If a file had five data components on five volumes, and one index component on its own volume, then it must be restored to six different volumes. FDRABR would select a volume with enough space for the first part of the VSAM file, but subsequent volumes selected may not have enough space. DFSMS will also get involved in picking out volumes. A release of FDRABR that came out in 2002 helped, because if it did not find the space on a volume it automatically retried the allocation a few times, but it is still possible to get errors.

If you know how many VSAM components, and therefore how many volumes you need, and if you can check manually to see that the space is available, then you can override all the automation and force the file to go where you want it to.

You will need one SELECT statement for every volume component of the multi-volume VSAM file. Each SELECT should specify the file by the cluster name, not DATA or INDEX component. If the DATASET is spread over three volumes, then three select statements are required.

RESTORE TYPE=ABR,DYNTAPE,DSNENQ=NONE,
SELECT   BYPASSSMS,BYPASSACS
SELECT   DSN=DWP.BILLING.RUN04,
    NEWI=DWT.TESTING,VOL=RX2208,
    NVOL=DX2016
SELECT   DSN=DWP.BILLING.RUN04,
    NEWI=DWT.TESTING,VOL=RX2200,
    NVOL=DX2019
SELECT   DSN=DWP.BILLING.RUN04,
    NEWI=DWT.TESTING,VOL=RX2204,
    NVOL=DX2000
SELECT   DSN=DWP.BILLING.RUN04,
    NEWI=DWT.TESTING,VOL=RX2200,
    NVOL=DX2019

Each NVOL must have enough contiguous free space to cope with the space used by the corresponding VOL.

FDRABR will try to restore each component individually. If one or two components fail, then you can rerun the job, but you must retain the SELECT statements that worked, and they must still point to the new volumes that worked. The SELECTS for the failing components can point to any other volume that has sufficient space, the error log in the failing job will tell you how much space is needed.

If you want to start again from scratch then you must clean up any restored components before trying again. The cluster will be allocated to a volume name like ####VK+, use ISPF line command DELETE / NOSCRATCH to get rid of it. The restore job will tell you if it managed to get any components back. These will be orphans, and need a 'DELETE / dsname VVR VOLUME(volser) DEVT(3390)' command from ISPF to get rid of them. If you don't do this, the next restore will probably fail with FDR157 9096-58 previous restore incomplete.

FDR cannot restore a multi-volume AIX. It must be rebuilt using IDCAMS

Common Recovery errors

The most common restore error message is an FDR321. This message has lots of reason codes, and the most common are explained below.

FDR321 reason code 2
no disk DD statement specified and the original volume is not available.
FDR321 reason code A
The ABR GEN, CYCLE and VOL backup information in the F1DSCB is not available for this dataset. This could be because the dataset was never backed up, or it has been moved to a different volume and the backup information is incorrect, or something has just corrupted it. If you can find out what volume the dataset was on when the backup ran, then you can get the volume GEN and CYCLE for that volume from the ABR catalog. You can then rerun your job with this information hard coded using GEN=, CYCLE= and VOL= parameters
FDR321 reason code D
An ABR datasets backup was identified from the F1DSCB or ABR Scratch information but that volume backup is not catalogued. If the tape has not been overwritten, you can use a TAPEDD parameter to point to the uncatalogued tape and run the restore.
FDR321 reason code K
Related to the error above, you have added a TAPEDD parameter in your control statements, but you did not add a TAPEx DD in the JCL
FDR321 reason code F
Either there was an IO error reading the FDRABR.V model DSCB, or the model does not exist. It is possible to override this error by specifying GEN=, CYCLE= and VOL= keywords.
FDR321 reason code G
This is a quite common error. Basically the dataset cannot be found because it is not catalogued to the system and there is no entry in the scratch catalog. Possible causes and solutions are
If the data set is not catalogued but exists online; specify VOL= in your SYSIN statements
The dataset is incorrectly catalogued to the wrong volume; catalog it up correctly
Your DSN or Volume name in your restore is incorrect - fix it
The data set is archived - recall it or use GEN=, CYCLE= and VOL= keywords.
The dataset was deleted and you have not installed the DADSM exit to record deletions in the ABR catalog; use GEN=, CYCLE= and VOL= keywords if you can work them out, and get the scratch exit installed for next time
FDR321 reason code H
The original volume that the data set existed on when it was backed up is not mounted. Either mount the volume, or use the GEN=, CYCLE= and VOL= parameters for the restore.
FDR321 reason code J
You have just specified a GEN= parameter in your SYSIN cards, you need to use both GEN= and CYCLE=
FDR321 reason code L
The data in the F1DSCB is empty so FDRABR went to the scratch catalog for the backup information but this was pointing to a different volume. Probably caused by the dataset being deleted and re-allocated. If the data in the scratch catalog is correct then use a VOL= statement that matches the catalog. Otherwise use a full set of GEN=, CYCLE= and VOL= parameters for the restore.
FDR321 reason code N
This probably means that your backup tape has been overwritten. If you don't have a copy2 then you probably cannot do the restore

back to top

  FDRABR pages

Lascon latest major updates