Restoring files using FDRABR.
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.
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
- If DFSMS is getting in your way, try BYPASSSMS,BYPASSACS. You may need RACF authorisation to use these.
- PRESTAGE means do not restore this file if it already exists online. This is useful if you want to restore files which are deleted, but miss out files which are cataloged and online.
- MAXCARDS. By default you can only have up to 100 SELECT or EXCLUDE statements. MAXCARDS lets you increase this limit
- COPY=2 means restore from your copy tape. This is used extensively in DR testing
- NEWNAME=new.file.name. This one is essential if the original file exists online, and you do not want to overwrite it.
- OLDBACKUP=nn. You often want to go back to an earlier backup than the most recent. OLDBACKUP lets you do this automatically. You would typically use the FDRABR ISPF panel to report on all available backups as shown below
DSN-INXP.MASTER.FDRJCL LAST REF--2004.005 DSORG----POE ****** BACKUP INFORMATION ****** BKD(00)-2004.003 SFX-C1004800 FN-0025 VOLS-A00975 BKD(01)-2003.360 SFX-C1004702 FN-0023 VOLS-A03697 BKD(02)-2003.358 SFX-C1004700 FN-0021 VOLS-A01125
The BKD(nn) entries are relative backup numbers, and next to them is the Julian data of the backup. So if you wanted a copy of this file from 2003.358 (December 22nd) then the relative backup is 02, so you specify OLDBACKUP=02. ABR then goes away and get the correct tape for you. ABR can track up to 13 old backups, but for this to work, the disks must be ABR initialised with the OLDBACKUP option set. See the ABR initialisation section for details.
- You can manually force ABR to restore from a specific backup, if you specify VOL=volser,GEN=gggg,CYCLE=cc You can get this information from a report like the one above, or from the output from your backup job. This is useful if ABR has lost its cataloging information, which can happen if the dataset has been moved or the backup tape has been uncatalogued.
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,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 wok 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