For this reason, it is important to use TimeFinder to create a gold copy of the
dependent-write consistent image on the secondary array.
SRDF/A session cleanup (SRDF/A)
When an SRDF/A single session mode is dropped, SRDF:
l
Marks new incoming writes at the primary array as being owed to the secondary
array.
l
Discards the capture and transmit delta sets, and marks the data as being owed to
the secondary array. These tracks are sent to the secondary array once SRDF is
resumed, as long as the copy direction remains primary-to-secondary.
l
Marks and discards only the receive delta set at the secondary array, and marks
the data is as tracks owed to the primary array.
l
Marks and discards only the receive delta set at the secondary array, and marks
the data is as tracks owed to the primary array.
Note
It is very important to capture a gold copy of the dependent-write consistent data on
the secondary array R2 devices prior to any resynchronization. Any resynchronization
compromises the dependent-write consistent image. The gold copy can be stored on a
remote set of BCVs or Clones.
Failback from R2 devices (SRDF/A)
If a disaster occurs on the primary array, data on the R2 devices represents an older
dependent-write consistent image and can be used to restart the applications.
After the primary array has been repaired, you can return production operations to the
primary array by following procedures described in
137.
If the failover to the secondary site is an extended event, the SRDF/A solution can be
reversed by issuing a personality swap. SRDF/A can continue operations until a
planned reversal of direction can be performed to restore the original SRDF/A primary
and secondary relationship.
After the workload has been transferred back to the primary array hosts, SRDF/A can
be activated to resume normal asynchronous mode protection.
Migration using SRDF/Data Mobility
Data migration is a one-time movement of data, typically of production data on an
older array to a new array. Migration is distinct from replication in that once the data
is moved, it is accessed only at the target.
You can migrate data between thick devices (also known as fully-provisioned or
standard devices) and thin devices (also known as TDEVs). Once the data migration
process is complete, the production environment is typically moved to the array to
which the data was migrated.
Note
Before you begin, verify that your specific hardware models and Enginuity or
HYPERMAX OS versions are supported for migrating data between different
platforms.
Remote replication solutions
140
Product Guide
VMAX 100K, VMAX 200K, VMAX 400K with HYPERMAX OS
Summary of Contents for VMAX 100K
Page 1: ...EMC VMAX3 Family Product Guide VMAX 100K VMAX 200K VMAX 400K with HYPERMAX OS REVISION 6 5 ...
Page 20: ...Preface 20 Product Guide VMAX 100K VMAX 200K VMAX 400K with HYPERMAX OS ...
Page 46: ...VMAX3 with HYPERMAX OS 46 Product Guide VMAX 100K VMAX 200K VMAX 400K with HYPERMAX OS ...
Page 72: ...Open systems features 72 Product Guide VMAX 100K VMAX 200K VMAX 400K with HYPERMAX OS ...
Page 82: ...Provisioning 82 Product Guide VMAX 100K VMAX 200K VMAX 400K with HYPERMAX OS ...
Page 158: ...Remote replication solutions 158 Product Guide VMAX 100K VMAX 200K VMAX 400K with HYPERMAX OS ...
Page 186: ...Mainframe Error Reporting 186 Product Guide VMAX 100K VMAX 200K VMAX 400K with HYPERMAX OS ...
Page 200: ...Licensing 200 Product Guide VMAX 100K VMAX 200K VMAX 400K with HYPERMAX OS ...
