Restoring a TCT Backup Control File From the Cloud

When the FDR system writes a backup to cloud storage, it also writes a small file on disk, called a backup control file. The backup control file contains information that is needed in order to do the restore. It is desirable that the backup control file remain on disk for as long as the backup is retained. However, the backup control file is also backed up to the cloud; if it is deleted from disk, then it can be restored from the cloud in order to be able to restore the data sets in the backup.

Automatic restore of the backup control file

For automatic recall, and other restores from ARCHIVE with DYNTAPE, and for restore from application backup (FDRAPPL) with DYNTAPE, the backup control file is restored automatically if it is missing from disk.

The restore may issue message IEC143I 213-04 (as though for an S213-04 ABEND) when it tries to OPEN the missing backup control file. The restore then recovers and restores the backup control file from the cloud. This process depends on certain options in the FDR Global Options table (FDROPT). These options are on ABR ISPF panel A.I.4.15. See Options for Auto Recall from Cloud Storage in ABR-Auto-Recall-Customization-Options and Set-FDRCLOUD-Options.

Important

If an installation Archives to cloud storage, and there is an exposure that the backup control files for the Archives may be deleted while the Archives are being retained, then for auto recall to succeed, all Archives must use the same cloud and the same container, and the names of this cloud and this container must be specified in the CLOUDNAME and CLOUDCNA options.

If the backup control files for ARCHIVEs are SMS-managed, and there is an exposure that the backup control files may be deleted while the Archives are being retained, then either the installation's ACS routines must be set up to assign appropriate SMS classes for the backup control files, or all backup control files for Archives must use the same SMS classes, and the names of these classes must be specified in the CLOUDDC, CLOUDSC, and CLOUDMC options.

FDRDSF restore of the backup control file

If the restore is not an automatic recall, or other restore from ARCHIVE with DYNTAPE, or a restore from application backup (FDRAPPL) with DYNTAPE, you can restore the backup control file with FDRDSF.

The backup control file can only be restored to the same DASD control unit that it was dumped from (or another control unit that is connected to the same cloud and is able to access the same containers).

To restore a backup control file from the cloud, you must supply information that FDRDSF would normally get from the backup.

  • Supply a TAPEx DD statement that allocates space for the data set. Ideally, this statement should be identical to the TAPEx DD statement that created the data set during the backup.
    • An exception is that if the backup control file is a GDG, the generation would be different. When the backup control file was created it would have been, for example, DSN=PROD.BACKUP.VSH20CC(+1), but at restore time it might be DSN=PROD.BACKUP.VSH20CC(-37); it would probably be more convenient to specify an absolute generation number, such as DSN=PROD.BACKUP.VSH20CC.G0142V00 .
    • If you do not know the space quantity, try SPACE=(TRK,15).
    • Any SMS classes that were specified originally should be specified the same, especially if they are necessary to get the backup control file allocated on the right control unit. If SMS classes were assigned by the ACS routines, then presumably the same classes will be assigned this time. SMS classes cannot be assigned by the SELECT statement, because the backup control file is allocated by JCL before the restore starts running.
  • On the SELECT command, specify CLOUD= and CONTAINER= . Normally the restore would get this information from the backup control file, but it can't when the backup control file itself is the data set being restored.

Important

The default container names in the FDR Global Options table (options CLOUDCNA/B/D/F/P) do not apply, because there are different default container names for different types of backups, but this restore is always under FDRDSF, and FDRDSF does not know in advance what type of backup created this backup control file.

Example:

//RESTORE EXEC PGM=FDRDSF //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //TAPE1 DD UNIT=SYSALLDA, // VOL=SER=SH20CF, // DSN=PROD.BACKUP.VSH20CC.G0142V00, // DISP=(NEW,CATLG), // SPACE=(TRK,15) //SYSIN DD * RESTORE TYPE=DSF, CLOUD=cloudname, CONTAINER=containername SELECT DSN=PROD.BACKUP.VSH20CC.G0142V00

Restore of a backup control file may produce the following message one or more times:

FDR151** I/O ERROR DSN=ICF1.TCTI062.VSH20CC.BKUP1 TCT307=RECALL : SIZE MISMATCH BETWEEN TARGET DAT

This is normal and not an error. TCT requires that the caller know the number of tracks in the object (data set) being restored. Ordinarily the restore gets this size from the backup control file, but it cannot when the backup control file itself is the data set being restored. The restore starts by requesting one track, and if it gets the above error it tries again, increasing by one track at a time until the restore works. If you happen to know how many tracks were used in the backup control file, you can enable the restore to work the first time by specifying NCP=n on the TAPEx DD statement, where n is the number of tracks used.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*