Administrator Guide

Disaster recovery
The replication feature supports manual disaster recovery only. It is not integrated with third-party disaster recovery software.
Since replication sets of virtual volumes cannot reverse the direction of the replication, carefully consider how the replicated
data will be accessed at the secondary backup site when a disaster occurs.
NOTE: Using a volume group in a replication set ensures consistent simultaneous copies of the volumes in the volume
group. This means that the state of all replicated volumes can be known when a disaster occurs since the volumes are
synchronized to the same point in time.
Accessing the data while keeping the replication set intact
If you want to continue replicating changed data from the primary data center system, you will need to keep the replication set
intact. While the data center system is down, you can access the data at the secondary backup system by creating a snapshot
of the secondary volume or using the snapshot history snapshot. The snapshot can be mapped either read-only or read-write
(but you cannot replicate the changes written to it back to the data center system using the existing replication set).
NOTE: If a system goes down but recovers, the data, peer connection, and replication sets should be intact and replication
can resume normally.
Access data at the backup site temporarily
1. Create a snapshot of the secondary volume or use a snapshot history snapshot.
2. Map the snapshot to hosts.
3. When the data center system has recovered, delete the snapshot.
Accessing the data from the backup system as if it were the
primary system
If you do not think the data center system can be recovered in time or at all, then you will want to temporarily access the data
from the backup system as if it were the primary system. You can again create a snapshot of the secondary volume and map
that to hosts, or delete the replication set to allow mapping the secondary volume directly to hosts. Deleting the replication set
means the secondary volume becomes a base volume and is no longer the target of a replication. Should the primary volume
become available and you want to use it as is in preparation for another disaster, a new replication set with a new secondary
volume must be created. Deleting the replication set also enables cleaning up any leftover artifacts of the replication set.
In an emergency situation where no connection is available to the peer system and you do not expect to be able to reconnect
the primary and secondary systems, use the local-only parameter of the delete replication-setand delete peer-
connection CLI commands on both systems to delete the replication set and peer connection. Do not use this parameter in
normal operating conditions. For more information, see the Dell EMC PowerVault ME4 Series Storage System CLI Guide. Other
methods for deleting replication sets and peer connections will most likely be ineffective in this situation.
NOTE:
While deleting the peer connection for the replication set is unnecessary for making the secondary volume
mappable, if you think that it will no longer be operable in the future, delete it when deleting the replication set.
Disaster recovery procedures
In a disaster recovery situation, you might typically perform the tasks in the following order:
1. Transfer operations from the data center system to the backup system (failover).
2. Restore operations to the data center system when it becomes available (failback).
3. Prepare the secondary system for disaster recovery.
122
Working in the Replications topic