Users Guide

Replication use cases
You can use replication for planned downtime, such as during inter-cluster migration, the installation of a major software update, and
disaster recovery.
Intercluster migration
If you need to migrate a storage object to another PowerStore cluster, you can set up a one-time replication between the two clusters,
followed by a planned fail over to the new cluster to complete the migration. After the migration, dismantle the source object to reclaim
space on the original cluster.
Using replication for planned downtime
Planned downtime is a situation where you take the source system offline for maintenance or testing, while operating off the destination
system. Before the planned downtime, both the source and destination are running with an active replication session. There is no data loss
in planned downtime.
In this scenario, the source system, Boston, is taken offline for maintenance, and the destination system, New York, is used as the
production system during the maintenance period. After maintenance is over, return production to the Boston system.
To start planned downtime, select Planned Failover on the Boston source system. The New York destination system is fully synchronized
with the source to ensure that there is no data loss. The session remains paused, while the Boston source system becomes read-only and
the destination becomes read/write. The New York destination storage resource can provide access to the host. On the New York
destination storage resource, select Reprotect to resume replication in the reverse direction.
To resume operations on the Boston system after maintenance, select Planned Failover on the New York system. After the failover is
complete, Reprotect on the Boston system.
NOTE:
To replicate data from the destination to the source with the reprotect operation, ensure that there is a
replication policy on the destination system that has a replication rule pointing to the source system. For example, if the
regular replication session is from a site in Boston to a site in New York, the replication policy on the destination storage
resource in New York must point to Boston.
Using replication for disaster recovery
In this disaster recovery scenario, the source system, Boston, is unavailable due to a natural or human-caused disaster. A destination
system, New York, was created, which contains a full copy, or replica, of the production data. Data access can be restored by failing over
to New York because a replication session was configured between the Boston and New York systems.
Using replicas for disaster recovery minimizes potential data loss. The replica is up-to-date with the last time that the destination
synchronized with the source, as specified in the associated replication rule. The amount of potential data loss is based on the recovery
point objective (RPO) setting in the associated replication rule. The replication session can be failed over to the New York destination
system, using the latest data that was replicated from Boston.
After the session is failed over to the New York system, it becomes read/write. When originally establishing a replication session between
the source and destination systems, the storage resource was given the correct access permissions to the host and share. Creating the
correct host access on the destination system ahead of time reduces downtime in an event of a disaster.
To resume operations on the Boston system, when it is available:
1. From the New York system, select the Reprotect option, which resumes the replication session in the reverse direction.
2. After the systems are synchronized, select the Planned Failover option on the New York system.
3. Select the checkbox to auto-reprotect the system after failing over. Or, after the failover is complete, on the Boston system, select
Reprotect.
NOTE:
To replicate data from the destination to the source with the reprotect operation, ensure that there is a
replication policy on the destination system that has a replication rule pointing to the source system. For example, if the
replication session is from a site in Boston to a site in New York, the replication policy on the target storage resource in
New York must point to Boston.
14 Use cases