Using Snapshot restore in a HyperSwap environment
You can avail of the ultimate level of data availability by restoring storage with IBM® Storage Protect Snapshot support for IBM HyperSwap technology.
You can use the relevant commands described in the topic Restoring DB2 databases.
HyperSwap restore limitations
Snapshot restore operations on master and auxiliary volumes are not possible without interrupting HyperSwap relations. During the interruption, high availability is lost. This is because current HyperSwap implementations do not support the creation of a FlashCopy mapping when the FlashCopy target volume is a master or auxiliary volume in a HyperSwap or remote copy relationship. Furthermore, current HyperSwap implementations do not support pausing or stopping a HyperSwap relationship. To create a FlashCopy mapping, the HyperSwap volume copy on the auxiliary site must be removed. At this point, the FlashCopy mappings for the change volumes and dual IO routing are also removed.

After a Snapshot HyperSwap restore, all HyperSwap settings must be reconfigured to a consistent and synchronized state. Current HyperSwap implementations do not support the creation of a remote copy relationship on master or auxiliary volumes that are the target of a FlashCopy mapping. When synchronization is complete, you can use a dynamically created shell script to automatically reconfigure the required relationships and IO settings. The reconfiguration script is named <timestamp>_hyperrel.sh, where <timestamp> is the current date and time. Run the reconfiguration script from the acs directory that is created when Snapshot is installed.
If successful, the reconfiguration script terminates silently. If for example the volume has copies in two sites using HyperSwap already or if other errors from the storage system are reported, the script will display those.
You can automate the execution of the reconfiguration script after a timeout interval defined by
the HYPERSWAP_RESTORE_TIMEOUT parameter in the Snapshot configuration file .
However, this approach runs the risk of the failure of the reconfiguration operation if the Snapshot
restore is late finishing. If the time required to perform a resynch is unpredictable, run the
reconfiguration script manually.
