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.
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 SRDF recovery operations on page
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.
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
To Next Page
Loading...
