Dell PowerStore 1200T EMC PowerStore Protecting Your Data - Page 32

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. 32 Use cases