Administrator Guide

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.
Manually transfer operations from the data center system to the
backup system
1. Create a snapshot of the secondary volume, use a snapshot history snapshot, or delete the replication set.
2. Map the snapshot or the secondary volume, depending on the option that you choose in step 1, to hosts.
Restore operations to the data center system
1. If the old primary volume still exists on the data center system, delete it. The volume cannot be used as the target—a new
“secondary” volume will be created and deleting it will free up available space.
116
Working in the Replications topic