Volume recovery from incremental backup versions

Normally volume recovery is run when an entire DASD pack has been lost or damaged or a significant amount of the data has become inaccessible. A copy of the VTOC made during the incremental backup of the volume is used to drive the individual incremental recovery of data sets for which DFSMShsm has backup versions. DFSMShsm volume recovery is also referred to as incremental volume recovery. After DFSMShsm successfully recovers a volume, each supported data set on the recovered volume is at the level of its latest backup. This recovers the data set to the most recent level unless someone changed the data set since the last time DFSMShsm backed it up.

The following commands cause volume recovery from incremental backup copies:

RECOVER * TOVOLUME(volser) UNIT(unittype)

RECOVER * TOVOLUME(volser) UNIT(unittype) DATE(date)

Volume recovery is similar to data set recovery in that DFSMShsm recovers each data set; DFSMShsm does not recover data track by track. First, a single task builds the queue of data sets that need to be recovered, then multitasking is used during the actual recovery of the data sets. If recovering multiple volumes, it is most efficient to first put a hold on tape data set recovers, then create the queue of data sets to be recovered, then release the tape data set recovery processing. Since data sets from different volumes may reside on one tape, recovering data sets for multiple volumes at the same time, rather than volume-by-volume, reduces the number of required tape mounts, and thus speeds processing. However, because DFSMShsm recovers each data set and because the backup operation uses backup volumes from different days, volume recovery can require access to many backup volumes just to recover one level 0 volume. As a result, volume recovery can be very time-consuming. Consider using the DFSMShsm full-volume dump restore facility (see Full-volume restore with update) to reduce the time required for recovery.

You can specify that backup versions be at least as recent as a particular date by specifying the DATE parameter of the RECOVER command. You must use the TOVOLUME parameter to identify an entire volume that you want to recover.

DFSMShsm uses the latest VTOC copy data set to recover the volume unless an error occurs in allocating or opening the latest VTOC copy data set. If the error occurs, DFSMShsm attempts to recover the volume, using the next latest copy of the VTOC copy data set. If a similar error occurs again, the volume recovery fails.

When DFSMShsm recovers a volume, it recovers the following:

Any base entries for a generation data group cataloged in the catalog residing on the volume being recovered.
Any integrated catalog facility user catalogs that do not already exist on the volume being recovered. For information about recovering an integrated catalog facility catalog, see Backing up and recovering a catalog.
All other data sets except the following:
- Catalogs
- VSAM data sets currently cataloged as MIGRAT
- ICF VSAM components
- Data sets that are cataloged as multiple-volume
- Non-VSAM data sets that are currently cataloged as MIGRAT but the selected backup version was made when the data set was cataloged
- Non-VSAM data sets that are currently cataloged as MIGRAT, the selected backup version was made when the data set was uncataloged, but the migration took place after the backup version was made
- Data sets that are cataloged on a volume other than the one being recovered when the backup version of a cataloged data set is selected for recovery
- Data sets that are currently cataloged on the volume being recovered but the backup version selected for recovery was uncataloged when it was backed up
- Data sets that were cataloged when backed up and but not currently cataloged
- Data sets whose creation date is later than the backup date
- Data sets that are not SMS-managed being recovered to a SMS-managed volume

DFSMShsm considers data sets uncataloged at the time they are backed up to be unique to the volume on which they reside. This is because multiple uncataloged data sets with the same name may exist on different volumes. Backup versions of uncataloged data sets will only be recovered to the volume from which they were backed up.

DFSMShsm considers a cataloged data set to be the same data set regardless of the volume on which it is currently cataloged. Therefore, DFSMShsm will recover the most current backup version of a cataloged data set regardless of the volume on which it was cataloged when it was backed up.

Table 1 shows the process of backup version data set selection for volume recovery.

Table 1. Backup Version Data Set Selection for Recovery
First Criterion	Second Criterion	Result
If only backup versions of cataloged data sets exist,	and if the data set is currently cataloged on the target volume,	then the cataloged backup copy is recovered.
	and if the data set is not currently cataloged,	then recovery of this data set fails.
	and if the data set is cataloged but not on the target volume,	then recovery is not attempted.
If only backup versions of uncataloged data sets exist,	and if the data set is currently cataloged on the target volume,	then recovery fails.
	and if the data set is not currently cataloged,	then the uncataloged backup version, made from this volume, is recovered.
	and if the data set is cataloged but not on the target volume,	then the uncataloged backup version, made from this volume, is recovered.
If backup versions of cataloged and uncataloged data sets exist,	and if both backup versions are from the target volume,	then DFSMShsm recovers the most recent backup copy. Recovery continues, depending on whether the data set was cataloged, as previously discussed.
	and if the backup version of a cataloged data set was made from a different volume, and the data set is currently cataloged on a volume other than the target volume,	then DFSMShsm attempts to recover the uncataloged backup version.
	and if the backup version of a cataloged data set was made from a different volume, but the data set is currently cataloged on the target volume,	then DFSMShsm attempts to recover the backup version of the cataloged data set.
	and if the backup version of a cataloged data set was made from a different volume, but the data set is not currently cataloged,	then DFSMShsm attempts to recover the uncataloged backup version.

For SMS-managed volumes, SMS must be active to recover the data sets that were backed up from that volume.

All non-VSAM SMS data sets are recovered to the volume being recovered. VSAM SMS data sets may be recovered to other volumes that are in the same storage group as the volume being recovered.

If DFSMShsm encounters a cataloged multiple-volume VSAM data set, it issues a message stating that the data set is multiple volume but does not recover the data set. If the multiple-volume data set is not cataloged or is presently cataloged as a single-volume data set, DFSMShsm recovers the data set if an eligible backup version exists.