August 15, 2017
© Copyright IBM Corporation, 2017 Page 73 of 117
Creating a New Primary/Secondary Copy after Disaster Recovery
If you have used the copy export recovery process because of a complete loss of the source TS7700, you
will likely want to set up the recovery TS7700 so that it will be able to be used to make a new secondary
copy of the data so that it can be taken to another site to protect the recovery TS7700 in the event of a future
disaster.
During the recovery process, the status of the physical volumes used in the recovery process depends on
whether the ‘Disaster Recovery Test Mode” is selected or not. If the checkbox is checked, the physical
volumes maintain a status of copy-exported. They are not changed to READ-WRITE. This is done to
prevent them from being exported in a subsequent copy export operation or reclaimed and re-used.
If the checkbox is unchecked, the state of the physical volumes is changed to READ-WRITE at code level
R1.4 and higher (at code level R1.3 the state is set to COPY_EXPORTED). They can be reclaimed and re-
used. However, since they contain the only copy of the logical volume (the copy export physical volumes
now contain the primary copy of the logical volumes at code level R1.3 and R1.4 and contain the secondary
copy at code level R1.5 and R1.6), they cannot be re-exported. You will need to take additional actions to
make another copy for a subsequent copy export operation.
To prepare the recovery TS7700 to perform subsequent copy export operations at code level R1.3 or R1.4
and to make the primary copy of the logical volumes ready for production at code level R1.5 or later, after
the recovery operation you will need to modify the storage management construct actions on the recovery
TS7700.
At pre R1.7 code, at a minimum you will need to change the definition for the management class name(s)
that specified the secondary physical volume pool. For R1.7 and later the volumes will need to be mounted
to re-establish the construct change.
For example, let’s say that in the original source TS7700, the primary physical volume pool used was pool 1
and the storage group that specified it was SGMAIN. The secondary physical volume pool used for copy
export was pool 9 and the management class name that specified that pool was MCPRIATL. In the recovery
TS7700 database (that was restored) the logical volumes will have retained that information. However, the
location of the primary copy of a logical volume has been changed to be that of the secondary physical
volumes used in the recovery operation at code level R1.3 and R1.4. At code level R1.5 and higher, the
secondary copy of a logical volume is located at the secondary physical volume pool. The physical volumes
used in the recovery will have been placed in pool 9 because that is what they were assigned to in the source
TS7700.
In the recovery TS7700 let’s assume you leave the storage group definition the same (you can change it if
you want, but it is not necessary). You will want to change the pool that is associated with the management
class name MCPRIATL and you will need to update the pool properties for that pool to indicate that it is an
export pool. That will now be the pool that is used for subsequent copy exports. Let’s assume that you
specify pool 10.
As you read or write data with the recovery TS7700, the TS7700’s storage management functions will
evaluate the prior and current storage management constructs definitions and perform the following actions:
• For a logical volume from the source TS7700 that is only read from
If the logical volume was one of the ones from the source TS7700, it will be recalled into the cache as
part of the mount request operation. When the volume is closed, the storage management functions will
see that the primary copy of the volume was previously assigned to pool 9, but that based on the
To Next Page
Loading...
Need help?
General
