HPE - A00088924en - Us - HPE Primera OS - Recovering From Disaster Using Remote

HPE Primera OS: Recovering from disaster using Remote Copy
Part Number: 20-PRI600-RCRE-ED2

Published: March 2022
Edition: 2
HPE Primera OS: Recovering from disaster using Remote Copy
Abstract
This guide is for system and storage administrators who perform disaster recovery functions on HPE Primera Remote Copy configurations.
Part Number: 20-PRI600-RCRE-ED2
Published: March 2022
Edition: 2
© Copyright 2019, 2022 Hewlett Packard Enterprise Development LP
Notices
The information contained herein is subject to change without notice. The only warranties for Hewlett Packard Enterprise products and
services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as
constituting an additional warranty. Hewlett Packard Enterprise shall not be liable for technical or editorial errors or omissions contained
herein.
Confidential computer software. Valid license from Hewlett Packard Enterprise required for possession, use, or copying. Consistent with FAR
12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed
to the U.S. Government under vendor's standard commercial license.
Links to third-party websites take you outside the Hewlett Packard Enterprise website. Hewlett Packard Enterprise has no control over and is
not responsible for information outside the Hewlett Packard Enterprise website.
Acknowledgments
Intel® , Itanium ® , Optane™, Pentium® , Xeon® , Intel Inside ® , and the Intel Inside logo are trademarks of Intel Corporation or its subsidiaries.
Microsoft ® and Windows ® are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other
countries.
Adobe® and Acrobat® are trademarks of Adobe Systems Incorporated.
Java® and Oracle® are registered trademarks of Oracle and/or its affiliates.
UNIX® is a registered trademark of The Open Group.

VMware® , VMware ® vCenter ™, and VMware vSphere ® are registered trademarks or trademarks of VMware, Inc. in the United States and/or
other jurisdictions.
Revision history
Part number Publication date Edition Summary of changes
20-PRI600-RCRE-ED2 March 2022 2 Updated for HPE Primera OS 4.5
20-PRI600-RCRE-ED1 October 2021 1 Updated for HPE Primera OS 4.4
P26629-003 May 2021 4 HPE Primera OS 4.3: Added Active Peer Persistence Remote Copy
support
P26629-002 June 2020 3 HPE Primera OS 4.2: Added three data center Peer Persistence
(3DC PP) support with both RCIP and RCFC
HPE Primera OS 4.2: Added synchronous long distance (SLD)
support with both RCIP and RCFC
P26629-001 January 2020 2 HPE Primera OS 4.1: Added HPE Primera Remote Copy over Fibre
Channel (RCFC) support
HPE Primera OS 4.0: Added synchronous long distance (SLD) with
IP links support
P23109-001 September 2019 1 Initial release

Table of contents
1 Recovering your 1-to-1, 1-to-N, or N-to-1 Remote Copy configuration

1.1 Failing over a Remote Copy group manually
1.2 Failing back after a failover of a Remote Copy group
1.3 Recovering a Remote Copy group
1.4 Restoring the direction of data flow in a Remote Copy group
2 Recovering your Active Peer Persistence or classic Peer Persistence configuration
2.1 Performing a switchover for Active Peer Persistence or classic Peer Persistence
2.2 Recovering an Active Peer Persistence or classic Peer Persistence failover
2.2.1 Recovering an Active Peer Persistence or classic Peer Persistence failover using CLI
2.3 Reversing the direction of data flow in an Active Peer Persistence or classic Peer Persistence group
2.4 Recovering Remote Copy groups in a failsafe status
2.4.1 Overriding failsafe for Remote Copy groups in a failsafe status
2.4.2 Recovering Remote Copy groups in a failsafe state with auto_synchronize on
2.4.3 Recovering Remote Copy groups in a failsafe state with auto_synchronize off
3 Recovering your synchronous long distance configuration
3.1 Failing over an SLD Remote Copy group manually
3.2 Reversing the roles of the SLD target systems after a failover
3.3 Recovering an SLD Remote Copy group
3.4 Restoring the direction of data flow in an SLD Remote Copy group
4 Recovering your three data center Peer Persistence configuration
4.1 Performing a switchover for 3DC PP
4.2 Recovering a 3DC PP failover after an automatic transparent failover
4.2.1 Recovering a 3DC PP configuration after an automatic transparent failover using CLI
4.3 Reversing the direction of data flow in a 3DC PP group
5 Reference: Disaster recovery for 1-to-1, 1-to-N, or N-to-1 Remote Copy configurations
5.1 Failover
5.1.1 Failover examples
5.2 Revert failover
5.2.1 Revert failover example
5.3 Recover
5.3.1 Recover example
5.4 Restore
5.4.1 Restore examples
5.5 Remote Copy group policies
6 Reference: Disaster recovery for Active Peer Persistence configurations
6.1 Active Peer Persistence switchover
6.1.1 Active Peer Persistence switchover example
6.2 Active Peer Persistence recover
6.2.1 Active Peer Persistence recover example
6.3 Active Peer Persistence reverse
6.3.1 Active Peer Persistence reverse example
6.4 Failsafe in an Active Peer Persistence configuration
6.5 VMware vSphere Metro Storage Cluster configuration
7 Reference: Disaster recovery for classic Peer Persistence configurations
7.1 Classic Peer Persistence switchover
7.1.1 Classic Peer Persistence switchover example
7.2 Classic Peer Persistence recover
7.2.1 Classic Peer Persistence recover example
7.3 Classic Peer Persistence reverse
7.3.1 Classic Peer Persistence reverse example
7.4 Failsafe in a classic Peer Persistence configuration
7.5 Nondisruptive failover in a classic Peer Persistence geo cluster environment
7.6 VMware vSphere Metro Storage Cluster configuration
8 Reference: Disaster recovery for SLD Remote Copy configurations
8.1 SLD failover to a synchronous target
8.1.1 SLD failover to a synchronous target example
8.2 SLD failover to a periodic target
8.2.1 SLD failover to a periodic target example
8.3 SLD reverse roles after a failover
8.3.1 SLD reverse roles example
8.4 SLD recover
8.4.1 SLD recover a synchronous target example
8.4.2 SLD recover a periodic target example
8.5 SLD restore
8.5.1 SLD restore a synchronous target example
8.5.2 SLD restore a periodic target example
9 Reference: Disaster recovery for 3DC PP Remote Copy configurations
9.1 3DC PP switchover
9.1.1 3DC PP switchover example
9.2 3DC PP recover
9.2.1 3DC PP recover example
9.3 3DC PP reverse
9.3.1 3DC PP reverse example
10 Related documentation
11 Websites
12 Support and other resources
12.1 Accessing Hewlett Packard Enterprise Support
12.2 Accessing updates
12.3 Remote support
12.4 Customer self repair
12.5 Warranty information
12.6 Regulatory information
12.7 Documentation feedback
Recovering your 1-to-1, 1-to-N, or N-to-1 Remote Copy configuration
Recovering your 1-to-1, 1-to-N, or N-to-1 Remote Copy configuration 6

Failing over a Remote Copy group manually
Perform a failover of a primary Remote Copy group if a primary volume fails. Perform a failover of all primary Remote Copy groups if the
source system becomes unavailable, or to perform maintenance on the source system.
Prerequisites
Hewlett Packard Enterprise recommends performing this task during planned downtime or low I/O activity as connectivity is impacted.
Procedure
1. Stop the Remote Copy group on the source system.
NOTE:
If the auto synchronize policy is enabled and the replication mode is synchronous, you do not need to stop the group.
2. On the HPE SSMC main menu, select Remote Copy Groups under DATA PROTECTION.
3. In the list pane, select the Remote Copy group, and then select Actions > Failover.
4. Click Failover.
5. To confirm the failover, select the check box about understanding the implications, and then click Yes, failover.
6. From the HPE SSMC Overview screen, confirm that the Remote Copy group is stopped.
7. Under the Health section of the Remote Copy groups page, confirm that the DR state is Failover.
More information
Failover
Remote Copy group policies
Failing over a Remote Copy group manually 7

Failing back after a failover of a Remote Copy group
To reverse a failover when the auto synchronize policy is not enabled, perform a failback. For example, if you failed over to perform
testing, failback to reverse the failover.
Prerequisites
A manual failover has occurred.
The DR state is Failover in the Health section of the Remote Copy groups page.
The reason for the failover is resolved and the Remote Copy links are up.
Procedure
2. In the list pane, select the Remote Copy group, and then select Actions > Revert Failover.
3. Click Revert Failover.
4. To confirm the failback action, select the check box about understanding the implications, and then click Yes, revert failover.
More information
Revert failover
Failing back after a failover of a Remote Copy group 8

Recovering a Remote Copy group
Manually recover a group if the auto synchronize policy is not enabled and the Remote Copy group failed over. For Peer Persistence
configurations, see Recovering an Active Peer Persistence or classic Peer Persistence failover.
Prerequisites
The reason for the failure is resolved and the Remote Copy links are up.
Procedure
2. In the list pane, select the Remote Copy group, and then select Actions > Recover.
3. By default, the Remote Copy group starts after the recover operation. To prevent the Remote Copy group from starting
automatically, select Do not start groups after role reversal is completed .
4. Click Recover.
5. To confirm the recovery, select the check box about understanding the implications, and then click Yes, recover.
6. (Optional) To change the group roles back to the original configuration, perform a restore.
More information
Recover
Recovering a Remote Copy group 9

Restoring the direction of data flow in a Remote Copy group
Prerequisites
The DR state is Failover or Recover in the Health section of the Remote Copy groups page.
Procedure
2. In the list pane, select the Remote Copy group, and then select Actions > Restore.
4. Click Restore.
5. To confirm the restore operation, select the check box about understanding the implications, and then click Yes, restore.
More information
Restore
Restoring the direction of data flow in a Remote Copy group 10

Recovering your Active Peer Persistence or classic Peer Persistence configuration
Recovering your Active Peer Persistence or classic Peer Persistence configuration 11

Performing a switchover for Active Peer Persistence or classic Peer Persistence
Prerequisites
The source and target Active Peer Persistence or classic Peer Persistence groups are in synchronous mode.
The source and target Active Peer Persistence or classic Peer Persistence groups are synchronized.
All volumes in the Active Peer Persistence or classic Peer Persistence groups have the same WWN.
All volumes have been exported to the same host sets from both storage systems.
The DR state is Normal in the Health section of the Remote Copy groups page.
Procedure
2. In the list pane, select the Active Peer Persistence or classic Peer Persistence group, and then select Actions > Switchover.
3. Click Switchover.
4. To confirm the switchover operation, select the check box about understanding the implications, and then click Yes, switchover.
More information
Classic Peer Persistence switchover
Nondisruptive failover in a classic Peer Persistence geo cluster environment
VMware vSphere Metro Storage Cluster configuration
Performing a switchover for Active Peer Persistence or classic Peer Persistence 12

Recovering an Active Peer Persistence or classic Peer Persistence failover
Recover an Active Peer Persistence or classic Peer Persistence group if the auto synchronize policy is not enabled and the group failed
over.
For storage systems with an HPE 3PAR OS or an HPE Primera OS 4.2 or earlier, perform Recovering an Active Peer Persistence or classic
Peer Persistence failover using CLI .
Prerequisites
Procedure
2. To synchronize the delta changes from the target to the source, perform a recover.
a. In the list pane, select the Active Peer Persistence group or classic Peer Persistence group, and then select Actions > Recover.
b. By default, the Active Peer Persistence or classic Peer Persistence group starts after the recover operation. To prevent the group
from starting automatically, select Do not start groups after role reversal is completed .
c. Click Recover.
d. To confirm the recovery, select the check box about understanding the implications, and then click Yes, recover.
3. Wait for the volumes to synchronize.
4. To reverse the replication direction, perform a reverse.
5. (Optional) To change the group back to the original configuration, perform a switchover.
More information
Classic Peer Persistence recover
Recovering an Active Peer Persistence or classic Peer Persistence failover 13

Recovering an Active Peer Persistence or classic Peer Persistence failover using CLI
In this procedure, SystemA identifies the primary or source storage system in the original configuration. SystemB identifies the
secondary or target storage system. During the failover, SystemA failed over to SystemB making SystemB the primary-rev
storage system. SystemB replicates to SystemA .
For more information about CLI commands, see the HPE Primera OS Command Line Interface Reference Guide .
Prerequisites
The DR state is Failover. To verify the DR state, issue the showrcopy groups command on the primary and secondary storage
systems in the Remote Copy configuration.
The Auto synchronize policy is not enabled.
The reason for the failure is resolved.
Procedure
1. Log in to the secondary (failover) storage system.
2. Recover the target system.
cli%
setrcopygroup recover -t <sync target>
Where: <sync target> is the name of the target on the primary system ( SystemA ).
The Remote Copy group on SystemA is changed from primary to secondary-rev.
3. Reverse the role of the Remote Copy groups.
cli%
setrcopygroup reverse -natural -t <sync target>
The Remote Copy group on SystemA is changed from secondary-rev to secondary. The Remote Copy group on SystemB is
changed from primary-rev to primary.
4. Wait for the volumes to synchronize.
cli%
showrcopy
5. (Optional) To change the groups back to the original configuration:
cli%
setrcopygroup switchover -t <sync target>
The Remote Copy group on SystemA is changed to primary. The Remote Copy group on SystemB is changed to secondary.
The replication direction changes so that SystemA replicates to SystemB .
Recovering an Active Peer Persistence or classic Peer Persistence failover using CLI 14
Reversing the direction of data flow in an Active Peer Persistence or classic Peer
Persistence group
Reverse in Active Peer Persistence or classic Peer Persistence is part of the disaster recovery process. This procedure applies to a classic
Peer Persistence or Active Peer Persistence Remote Copy group that is in a Recover state. If you need to reverse the direction of data
flow when the DR state is Normal, perform a switchover.
Prerequisites
The DR state is Recover in the Health section of the Remote Copy groups page.
Procedure
2. In the list pane, select the Active Peer Persistence group or classic Peer Persistence group in a Recover state, and then select Actions
> Reverse.
3. Click Reverse.
4. To confirm the reverse, select the check box about understanding the implications, and then click Yes, reverse.
More information
Classic Peer Persistence reverse
Reversing the direction of data flow in an Active Peer Persistence or classic Peer Persistence group 15
Recovering Remote Copy groups in a failsafe status
In this example, the failed and recovered storage system is the primary system. One or more Remote Copy groups on the primary system
show a failsafe status. The failover storage system is the secondary system.
WARNING:
Do not perform an override or any recovery action until you determine the roles of theRemote
Copy groups in a failsafe status.
Prerequisites
Both storage systems are ready to resume normal operations.
Procedure
1. Log into the failover (secondary) system.
2. For each Remote Copy group in a failsafe status, determine the role of those groups on the failover system.
cli%
showrcopy
If the Role of the Remote Copy group on the failover storage system is Secondary , perform Overriding failsafe for Remote
Copy groups in a failsafe status for that Remote Copy group.
If the Role of the Remote Copy group on the failover storage system is Primary or Primary_Rev , DO NOT perform an
override. Go to the next step.
3. For each Remote Copy group in a failsafe status, determine the auto_synchronize policy for the group.
If the Remote Copy group Policy shows auto_synchronize , perform Recovering Remote Copy groups in a failsafe
state with auto_synchronize on.
If the Remote Copy group Policy does not show auto_synchronize , perform Recovering Remote Copy groups in a
failsafe state with auto_synchronize off.
More information
Failsafe in a classic Peer Persistence configuration
Recovering Remote Copy groups in a failsafe status 16

Overriding failsafe for Remote Copy groups in a failsafe status
The failed (primary) storage system is ready to resume normal operations, but the Status for one or more Remote Copy groups
shows Failsafe .
WARNING:
Do not use the override command if the role of the Remote Copy group on the failover storage
system is Primary or Primary-rev . Use of the override command when the failover
storage system has become active causes data loss because the failover system might have
processed I/O. If you cannot determine the role of the storage systems, contact HPE Support.
Prerequisites
A Remote Copy group on the failover storage system shows Secondary role.
Procedure
1. Log in to the failed and recovered (primary) storage system.
2. If a Remote Copy group has a failsafe status, override failsafe for that group.
cli% setrcopygroup override <group_name>
Where:
<group_name> —Specifies the name of the Remote Copy group.
3. If all the Remote Copy groups on the primary storage system have a failsafe status, override failsafe for the system.
cli% setrcopygroup override <target_name>
Where:
<target_name> —Specifies the name of the secondary (failover) system.
4. Start each Remote Copy group.
cli% startrcopygroup <group_name>
More information
Overriding failsafe for Remote Copy groups in a failsafe status 17

Recovering Remote Copy groups in a failsafe state with auto_synchronize on
In this example, the failed and recovered storage system is the primary system ( SystemA ). The failover storage system is the
secondary system ( SystemB ).
Prerequisites
Procedure
1. Log in to the failover storage system.
2. Confirm the Remote Copy links are up.
cli%
showrcopy links
If the links are up, the configuration automatically recovers. Continue to the next step.
If the links are not up, troubleshoot the problem. See HPE Primera OS: Troubleshooting your Remote Copy configuration . Wait
for the links to come up and then continue to the next step.
3. Wait for the volumes to synchronize (the SyncStatus shows Synced ).
cli%
showrcopy
If synchronization completes, go to step 5.
If the volumes do not synchronize, go to the next step.
4. To determine if the volumes are in a normal state, check the primary (failed) storage system.
cli%
showvv -rcopygroup <group_name>
Where: <group_name> is the name of the Remote Copy group.
If the volumes are normal but auto synchronization did not occur, perform Recovering Remote Copy groups in a failsafe state
with auto_synchronize off.
If the volumes are not normal, troubleshoot the problem. When the volumes are in a ready state, perform Recovering Remote
Copy groups in a failsafe state with auto_synchronize off.
5. Wait for the Remote Copy groups to recover.
6. (Optional) To change a Remote Copy group back to the original configuration:
cli%
setrcopygroup switchover <group_name>
More information
Recovering Remote Copy groups in a failsafe state with auto_synchronize on 18

Recovering Remote Copy groups in a failsafe state with auto_synchronize off
In this example, the failed and recovered storage system is the primary system ( SystemA ). The failover storage system is the
secondary system ( SystemB ).
Prerequisites
Procedure
1. Log in to the failover storage system.
2. Confirm the Remote Copy links are up.
cli%
showrcopy links
If the links are up, go to the next step.
If the links are not up, troubleshoot the problem. See HPE Primera OS: Troubleshooting your Remote Copy configuration . Wait
for the links to come up and then continue to the next step.
3. Recover the target group.
cli%
setrcopygroup recover -t <sync target>
Where: <sync target> is the name of the target Remote Copy group on the primary system ( SystemA ).
4. Wait for the volumes to synchronize (the SyncStatus shows Synced ).
cli%
showrcopy
5. Reverse the role of the Remote Copy group.
cli%
setrcopygroup reverse -natural -t <sync target>
cli%
setrcopygroup switchover -t <sync target>
More information
Recovering Remote Copy groups in a failsafe state with auto_synchronize off 19

Recovering your synchronous long distance configuration
NOTE:
After recovering the primary from the tertiary site, after a failover of both the primary and secondary systems, Hewlett
Packard Enterprise recommends performing a full copy to the secondary site.
Recovering your synchronous long distance configuration 20

Failing over an SLD Remote Copy group manually
Perform a failover to one of the target systems if the source system becomes unavailable, or to perform maintenance on the source
system. The target must be functioning properly and not affected by the situation that took the primary system offline.
The group should be in a stopped state first if:
Failing over to the synchronous target and auto_synchronize is not set.
Failing over to the periodic target.
Procedure
2. In the list pane, select the SLD Remote Copy group, and then select Actions > Stop.
3. Select All targets.
4. Select Actions > Failover.
5. Select the target system to which you want to fail over in the Failover to drop-down list.
6. If you do not want the Remote Copy groups on the target system to start after role reversal, select Do not start groups after role
reversal is completed.
7. Click Failover.
8. To confirm the failover, select the check box about understanding the implications, and then click Yes, failover.
More information
SLD failover to a synchronous target
SLD failover to a periodic target
Failing over an SLD Remote Copy group manually 21

Reversing the roles of the SLD target systems after a failover
Prerequisites
Procedure
2. In the list pane, select the SLD Remote Copy group, and then select Actions > Switch failover.
3. Click Switch failover.
4. To confirm the failover, select the check box about understanding the implications, and then click Yes, switch failover.
More information
SLD reverse roles after a failover
Reversing the roles of the SLD target systems after a failover 22

Recovering an SLD Remote Copy group
Prerequisites
Procedure
2. In the list pane, select the SLD Remote Copy group, and then select Actions > Recover.
4. Click Recover.
5. To confirm the recovery, select the check box about understanding the implications, and then click Yes, recover.
6. (Optional) To change the groups back to the original configuration, perform a restore.
More information
SLD recover
Recovering an SLD Remote Copy group 23

Restoring the direction of data flow in an SLD Remote Copy group
Prerequisites
The DR state is either Failover or Recover in the Health section of the Remote Copy groups page.
Procedure
2. In the list pane, select the SLD Remote Copy group, and then select Actions > Restore.
3. Click Restore.
4. To confirm the restore operation, select the check box about understanding the implications, and then click Yes, restore.
More information
SLD restore
Restoring the direction of data flow in an SLD Remote Copy group 24

Recovering your three data center Peer Persistence configuration
Recovering your three data center Peer Persistence configuration 25

Performing a switchover for 3DC PP
A switchover changes the roles and replication direction of the groups from primary to secondary without impacting the host I/O.
Perform a switchover if service or maintenance must be performed on the source system in the configuration.
Prerequisites
The three data center Peer Persistence (3DC PP) group has a source and target in synchronous mode.
TIP:
HPE SSMC automatically selects the storage system with the synchronous target.
The volumes in the source and target are synchronized.
All volumes in the source and target have the same WWN.
All volumes were exported to the same host from both storage systems.
The DR state is Normal in the Health section of the Remote Copy groups page.
Procedure
2. In the list pane, select the 3DC PP group, and then select Actions > Switchover.
3. Click Switchover.
4. To confirm the switchover operation, select the check box about understanding the implications, and then click Yes, switchover.
More information
3DC PP switchover
Performing a switchover for 3DC PP 26

Recovering a 3DC PP failover after an automatic transparent failover
Recover a three data center Peer Persistence (3DC PP) group if the auto synchronize policy is not enabled and the group failed over.
For storage systems with an HPE Primera OS 4.2 or earlier, perform Recovering a 3DC PP configuration after an automatic transparent
failover using CLI.
Prerequisites
The primary or source system is back online.
Procedure
2. To synchronize the delta changes from the target to the source, perform a recover.
a. In the list pane, select the 3DC PP group, and then select Actions > Recover.
b. By default, the 3DC PP group starts after the recover operation. To prevent the Remote Copy group from starting automatically,
select Do not start groups after role reversal is completed .
c. Click Recover.
d. To confirm the recovery, select the check box about understanding the implications, and then click Yes, recover.
3. To reverse the replication direction, perform a reverse for 3DC PP.
4. (Optional) To change the groups back to the original configuration, perform a switchover for 3DC PP.
More information
3DC PP recover
Recovering a 3DC PP failover after an automatic transparent failover 27

Recovering a 3DC PP configuration after an automatic transparent failover using CLI
For storage systems with an HPE Primera OS 4.3 or later, perform Recovering a 3DC PP failover after an automatic transparent failover .
If an automatic failover occurs, restore the Remote Copy group back to the original configuration. In this procedure, SystemA
identifies the primary or source storage system in the original configuration. SystemB identifies the secondary or target storage
system. SystemC is the tertiary system. During the automatic transparent failover, SystemA failed over to SystemB .
Prerequisites
The DR state is Failover. To verify the DR state, issue the showrcopy groups command on the primary and secondary storage
systems in the Remote Copy configuration.
The Auto synchronize policy is not enabled.
The primary or source system is back online.
Procedure
1. Log in to the secondary (failover) storage system ( SystemB ).
2. Recover the target system.
cli%
setrcopygroup recover –t <sync target>
Where: <sync target> is the name of the target on the primary system ( SystemA ).
3. Reverse the role of the Remote Copy groups.
cli%
setrcopygroup reverse -natural –t <sync target>
4. Wait for the volumes to synchronize. To check the status:
cli%
showrcopy
cli%
setrcopygroup switchover –t <sync target>
More information
3DC PP recover
Recovering a 3DC PP configuration after an automatic transparent failover using CLI 28

Reversing the direction of data flow in a 3DC PP group
Reverse in 3DC PP is part of the disaster recovery process. This procedure applies to a Peer Persistence Remote Copy group that is in a
Recover state. If you need to reverse the direction of data flow when the DR state is Normal, perform a switchover for 3DC PP.
Prerequisites
The DR state is Recover in the Health section of the Remote Copy groups page.
Procedure
2. In the list pane, select the Peer Persistence group in a Recover state, and then select Actions > Reverse.
3. Click Reverse.
4. To confirm the reverse, select the check box about understanding the implications, and then click Yes, reverse.
More information
3DC PP reverse
Reversing the direction of data flow in a 3DC PP group 29

Reference: Disaster recovery for 1-to-1, 1-to-N, or N-to-1Remote Copy configurations
Reference: Disaster recovery for 1-to-1, 1-to-N, or N-to-1 Remote Copy configurations 30
Failover
A failover changes the secondary Remote Copy groups on the target system to primary. A failover provides the host with read/write
access to the volumes in the Remote Copy group on the target system.
Perform a failover if the source system becomes unavailable, or to perform maintenance on the source system.
A failover operation responds differently based on the auto synchronize policy setting.
An Auto synchronize policy enabled failover operation:
Changes the Remote Copy group Target role from Secondary to Primary.
Changes the host access to read-only for the volumes in the Remote Copy group on the source system.
Keeps the DR state as Normal.
An Auto synchronize policy is not enabled failover operation:

Changes the Remote Copy group Target role from Secondary to Primary-Rev.
Maintains the host read/write access to the volumes in the Remote Copy group on the source system.
Changes the DR state to Failover.
Failover 31
Failover examples
The following examples show the state of sysA (source) and sysB (target) before and after a failover, with and without the auto
synchronize policy enabled.
Example when auto synchronize policy is enabled
System or field name Before failover After failover

sysA Source, primary, read/write access Target, secondary, read-only access
sysB Target, secondary, read-only access Source, primary, read/write access
Group state Stopped. Started if the replication Mode is Sync. Started
DR state Normal Normal
Replication direction Stopped. If the Mode is Sync and the group is Started from SysB to SysA
started, replication occurs from SysA to SysB .
Example when auto synchronize policy is not enabled
sysA Source, primary, read/write access Source, primary, read/write access
sysB Target, secondary, read-only access Target, primary-rev, read/write access
Group state Stopped Stopped
DR state Normal Failover
Replication direction Stopped Stopped
Failover examples 32
Revert failover
Reverting a failover reverses the manual failover operation and restores the data to a prefailover state. Reverting returns the I/O from
the secondary location back to the primary location.
For example: you performed a failover to perform testing on the failover system. To restore the original data and not the test data,
perform a revert failover.
NOTE:
If the auto synchronize policy is enabled and you want to restore the original data and not the test data, perform
another failover.
A revert failover operation:

Changes the Remote Copy group on the source system back to primary and the target system back to secondary.
Provides the host read/write access to the volumes in the Remote Copy group on the source system. The hosts connected to the
target system are read-only.
Changes the DR state from Failover to Normal.
Revert failover 33
Revert failover example
The following example shows the state of sysA (source) and sysB (target) before and after a revert failover.
System or field name Before revert failover After revert failover
sysB Target, primary-rev, read/write access Target, secondary, read-only access
Group state Stopped Stopped
DR state Failover Normal
Replication direction Stopped Stopped

After you perform the revert failover and start the
Remote Copy group, the replication starts from
sysA to sysB .
Revert failover example 34

Recover
Recover changes the primary Remote Copy groups on the target system to secondary groups and then starts and synchronizes all
groups. Recover does not return the configuration to a prefailover state. To start data synchronization and immediately return to a
prefailover state, perform a restore.
A recover operation:
Reverses the direction of replication.
Synchronizes the delta changes from the target to the source storage system for a Remote Copy group.
Changes the Remote Copy group Source role to Secondary-Rev.
Prevents hosts connected to the source system from having write access on the LUNs that are associated with the virtual volumes in
the Remote Copy group.
Recover 35
Recover example
The following example shows the state of sysA (source) and sysB (target) before and after a recover.
System or field name Before recover After recover
sysA Source, primary, read/write access Source, secondary-rev, read-only access
sysB Target, primary-rev, read/write access Target, primary-rev, read/write access
Group state Stopped. Started. Stopped if you selected Do not start

groups after role reversal is completed.
DR state Failover Recover
Replication direction Stopped Started from sysB to sysA . Replication is

stopped if you selected Do not start groups after
role reversal is completed.
Recover example 36
Restore
Restore brings the Remote Copy group back to a prefailover state. It restores the group roles and replication direction.
If the DR state is Failover, the restore operation performs a recover and a restore to bring the Remote Copy group to a prefailover state.
A restore operation:
Changes the Remote Copy group Target role from Primary-Rev to Secondary. The Source role changes to Primary.
Changes the DR state to Normal.
Provides the host with read/write access to the volumes on the source system. The hosts connected to the target system are read-
only.
Restore 37
Restore examples
The following examples show the state of sysA (source) and sysB (target) before and after a restore based on the DR state.
Example when DR is in failover state
System or field name Before restore After restore
Group state Stopped Started. The group state is stopped if you selected
Do not start groups after role reversal is
completed.
Replication direction Stopped Started from sysA to sysB . Replication is

stopped if you selected Do not start groups after
role reversal is completed.
Example when DR is in recover state

sysA Source, secondary-rev, read-only access Source, primary, read/write access
Group state Started. Stopped if you selected Do not start Started. Stopped if you selected Do not start
groups after role reversal is completed. groups after role reversal is completed.
DR state Recover Normal
Replication direction Started from sysB to sysA . Replication is Started from sysA to sysB . Replication is
stopped if you selected Do not start groups after stopped if you selected Do not start groups after
role reversal is completed. role reversal is completed.
Restore examples 38
Active Peer Persistence ( active_active )
Volumes in the specified group will be enabled for host reads and writes from both the primary and the secondary.
When this policy is set, the auto_recover and auto_synchronize polices are automatically set and override (take precedence over)
the path_management and auto_failover policies. The HPE Quorum Witness is required for automatic failover of host IO when the
storage system containing the primary groups fails.
no_active_active
As the default setting, the no_active_active policy changes the Remote Copy group back to Passive/Active operation as
long as the path_management policy is set. If the path_managment policy is not set, the Remote Copy group operation changes
back to synchronous mode.
Auto failover ( auto_failover )
The auto failover policy, when enabled with HPE Quorum Witness, allows an automatic failover on a classic Peer Persistence
Remote Copy group. If the primary storage system fails, the group fails over to the secondary storage system automatically.
The auto failover policy also enables Remote Copy group failover for a RAID set failure or metadata corruption of a primary
volume in the group. Although the failover does not require a Quorum Witness configuration, it does require the
path_management policy or active_active policy. While restarting the group after the failover, a full synchronization of the volumes
is performed which ensures consistency.
If the auto failover policy is not enabled, if a disaster occurs, the classic Peer Persistence group does not fail over and must be
recovered manually.
NOTE:
The active_active policy takes precedence over this policy. It can be left enabled when enabling Active Peer
Persistence. It can be disabled after conversion to Active Peer Persistence has completed. If left enabled,
subsequent disabling of Active Peer Persistence results in going back to automatic transparent failover for Classic
Peer Persistence groups.
NOTE:
The Primera OS 4.3.x introduces auto failover upon loss of host access to volumes in Remote Copy groups and
when the storage system is shutdown. If all the host IO paths to one or more volumes are down, the primary
Remote Copy groups will automatically failover to the secondary storage system. If the storage system containing
the primary Remote Copy groups is shutdown using the OS shutdown command, and the active_active policy is set,
the primary Remote Copy groups will automatically failover to the secondary storage system.
no_auto_failover
As the default setting, use the no_auto_failover policy to select Remote Copy groups that will not be subject to automatic
failover. This policy setting disables all failover strategies.
Auto recover ( auto_recover )
When enabled, if a Remote Copy link goes down, the Remote Copy group is restarted automatically after the links recover.
If you enable the auto recover policy when the links are down and the Remote Copy group is stopped, the group does not
automatically restart when the links recover. However, if auto recover is set and the links fail, and then you disable the policy, the
Remote Copy group does not restart automatically after the links recover.
The auto recover policy is enabled by default when the active_active policy is enabled. This policy is enabled automatically
when the active_active policy is set. When not enabled, you must restart the Remote Copy group manually after the links recover.
no_auto_recover
As the default setting, the no_auto_recover policy setting disables the automatic recover policy. Therefore, Remote Copy
groups are never automatically restarted.
Auto synchronize ( auto_synchronize )
If a failover occurs and the auto synchronize policy is enabled, all virtual volumes in the Remote Copy group will be automatically
synchronized. Synchronization occurs after system recovery completes and the Remote Copy links recover.
Hewlett Packard Enterprise recommends that setting the auto synchronize policy as a best practice for all configurations.
In synchronous long distance (SLD) and three data center Peer Persistence (3DC PP) configurations, this policy can be set on the
Remote Copy group synchronous targets only.
NOTE:
In SLD configurations, to perform a failover to the synchronous target, the SLD group must be stopped on all
Remote Copy group policies 39

targets, or started on all targets. To perform a failover to the periodic target, the SLD group must be stopped on all
targets.
In 3DC PP configurations, the target links must be down to perform a failover to the synchronous target. To
perform a failover to the periodic target, the groups on the periodic target must be stopped. The links can be up or
down.
The auto synchronize policy is enabled by default when the active_active policy is enabled. When not enabled, you must manually
synchronize the Remote Copy group after the system recovery completes and after the links recover.
no_auto_synchronize
To select Remote Copy groups that will not be subject to automatic synchronization after failover, use the
no_auto_synchronize policy. This policy is the default setting.
Mirror ( mirror_config )
The mirror policy automatically applies actions and settings to the Remote Copy group at the source and target storage systems
simultaneously. For example, if you start or stop a Remote Copy group, the group starts or stops on the source and target systems
simultaneously. You can start or stop the Remote Copy group even if the target storage system is disconnected from HPE SSMC.
The mirror policy option is automatically enabled when you create a Remote Copy configuration.
Over period alert ( over_per_alert )
If periodic synchronization does not complete within the specified synchronization period, the over period alert policy generates
alerts.
The over period alert policy is enabled by default for periodic Remote Copy groups. This policy applies to periodic mode only.
no_over_per_alert
If you do not want to generate slow synchronization alerts for asynchronous periodic Remote Copy groups, use the
no_over_per_alert policy setting.
Peer Persistence ( path_management )
The classic Peer Persistence policy sets the Asymmetric Logical Unit Access (ALUA) path from the host to the primary Remote
Copy group to active. The path to the secondary Remote Copy group is set to standby.
If classic Peer Persistence is not enabled, ALUA behavior is not enabled for volumes in the Remote Copy group. In a 3DC PP
configuration, the policy is only applied to the synchronous groups.
The Active Peer Persistence policy takes precedence over this policy. It can be left enabled when enabling Active Peer Persistence.
It can be disabled after conversion to Active Peer Persistence has completed. If left enabled, subsequent disabling of Active Peer
Persistence results in going back to Classic Peer Persistence operation.
IMPORTANT:
You cannot disable the path_management policy on volumes that are presented to hosts from both the primary
and secondary systems in a classic Peer Persistence configuration. The policy can only be disabled after volume
presentation is removed from the secondary system or when Active Peer Persistence is enabled.
no_path_management
Use the no_path_management setting to disable the path management policy for synchronous Remote Copy groups. The
Target Port Group state of volumes in the specified group will be reported as ACTIVE on the primary and secondary
systems.
For example:
cli% setrcopygroup pol no_path_management <group>
This policy is the default setting.
Multi-target Peer Persistence ( mt_pp )
The multi-target Peer Persistence policy enables the primary Remote Copy groups to update the secondary groups synchronously
with a Peer Persistence target and periodically to a tertiary site. The policy must be set on all group targets in a 3DC PP
configuration.
This policy is required for 3DC PP configurations.
no_mt_pp
Use the no_mt_pp policy to remove multi-target replication in a classic Peer Persistence configuration. This policy is the
default setting.
Remote Copy group policies 40

Reference: Disaster recovery for Active Peer Persistence configurations
Reference: Disaster recovery for Active Peer Persistence configurations 41

Active Peer Persistence switchover
A switchover changes the roles of the Active Peer Persistence groups and reverses the replication direction without impacting the host
I/O. The source volume becomes the target, the target volume becomes the source, and the paths between them are reversed from the
original configuration. A switchover is also called a manual transparent failover.
Perform a switchover if service or maintenance must be performed on the source system in the Active Peer Persistence configuration. A
switchover:
Changes the Remote Copy Active Peer Persistence group Target role of the target systems. The primary group becomes secondary
and the secondary group becomes the primary system.
Changes the replication direction.
Provides the host with read/write access that stays the same as before switchover.
Active Peer Persistence switchover 42

Active Peer Persistence switchover example
The following example shows the state of sysA (source) and sysB (target) before and after a switchover.
System or field name Before switchover After switchover
sysA Source, primary, read/write access Target, secondary, read/write access
sysB Target, secondary, read/write access Source, primary, read/write access
Group state Started Started
Replication direction sysA to sysB sysB to sysA
Active Peer Persistence switchover example 43

Active Peer Persistence recover
Recover synchronizes the delta changes from the target group to the source group.
An Active Peer Persistence recover operation:
Synchronizes the delta changes from the target to the source storage system for an Active Peer Persistence group.
Changes the Active Peer Persistence group Source role to Secondary-Rev.
Active Peer Persistence recover 44

Active Peer Persistence recover example
sysA Source, primary, read/write access Target, secondary-rev has read/write access if the
group is started and sync of the delta changes has
completed.
Target, secondary-rev, read-only access.
sysB Target, primary-rev, read/write access Source, primary-rev, read/write access
Group state Stopped Started. Stopped if you selected Do not start

Replication direction Stopped sysB to sysA
Active Peer Persistence recover example 45

Active Peer Persistence reverse
Reverse changes the roles of the Active Peer Persistence Remote Copy group. Reverse brings the group back to a Normal DR state.
However, the original target system is now the source system.
A reverse operation:
Changes the Remote Copy group Source role from Secondary-rev to Secondary.
Changes the Remote Copy group Target role from Primary-rev to Primary.
Active Peer Persistence reverse 46

Active Peer Persistence reverse example
The following example shows the state of sysA (source) and sysB (target) before and after a reverse.
System or field name Before reverse After reverse
sysA Target, secondary-rev, read/write access if the Target, secondary, read/write access if the Remote
Remote Copy group was in a started and synced Copy group is in a started and synced state after
state before reverse. reverse.
sysB Source, primary-rev, read/write access. Source, primary, read/write access.
Replication direction sysB to sysA sysB to sysA
Active Peer Persistence reverse example 47

Failsafe in an Active Peer Persistence configuration
In an Active Peer Persistence configuration, the LUN on both storage systems is assigned the same WWN. These physically separate
volumes with the same WWN allow a host to see the same LUN with different paths. So if a failover occurs, the host can continue its I/O
operations uninterrupted.
When the Remote Copy group is in a DR state, failsafe is used to prevent the volumes from becoming writable on both systems
simultaneously. Failsafe helps prevent data inconsistency between primary and secondary volumes when the volumes have the same
WWN. Failsafe can occur even in non-Peer Persistence configurations, if the volumes have the same WWN.
For example: The primary storage system fails (loses power, crashes, or reboots). The primary Remote Copy groups fail over to the
secondary storage system. When the primary storage system comes back up, the volumes in the primary groups are in a failsafe status
until the primary storage system determines the status of the secondary storage system.
For example: The primary storage system cannot communicate because the Remote Copy links and Quorum Witness communications are
down. A failover to the secondary storage system occurs and all volumes in the primary Remote Copy groups on the primary storage
system are placed into a failsafe status.
Failsafe in an Active Peer Persistence configuration 48

VMware vSphere Metro Storage Cluster (vMSC) is an example of a geo cluster, stretched cluster, or Metrocluster configuration. To
achieve high availability across host and storage system sites, host clusters use VM and/or cluster resource affinity and failover rules.
Hewlett Packard Enterprise supports vMSC uniform configurations. Uniform host access is a VMware-stretched cluster configuration
where each host can access storage resources available at both sites. It is geared towards protecting against a storage failure at a site.
Only a uniform configuration works with Active Peer Persistence or classic Peer Persistence to provide transparent failover without host
interruption.
Uniform host access provides:
Protection against storage failure
Active load balancing
The uniform host access configuration is a requirement to achieve the host transparent aspects of Active Peer Persistence or classic
Peer Persistence failover or switchover.
Figure 12: VMware vMSC certification—uniform host access
VMware vSphere Metro Storage Cluster configuration 49

Reference: Disaster recovery for classic Peer Persistence configurations
Reference: Disaster recovery for classic Peer Persistence configurations 50

Classic Peer Persistence switchover
A switchover changes the roles of the classic Peer Persistence groups and reverses the replication direction without impacting the host
I/O. The source volume becomes the target, the target volume becomes the source, and the paths between them are reversed from the
original configuration. A switchover also makes the LUNs writable from hosts connected to both systems. A switchover is also called a
manual transparent failover.
Perform a switchover if service or maintenance must be performed on the source system in the classic Peer Persistence configuration. A
switchover:
Changes the Remote Copy classic Peer Persistence group Target role of the target systems. The primary group becomes secondary
and the secondary group becomes the primary system.
Provides the host with read/write access to the volumes on the secondary group.
Classic Peer Persistence switchover 51

Classic Peer Persistence switchover example
The following example shows the state of sysA (source) and sysB (target) before and after a switchover in a classic Peer Persistence
configuration.

sysA Source, primary, read/write access Target, secondary, No read/write access
sysB Target, secondary, No read/write access Source, primary, read/write access
Replication direction sysA to sysB sysB to sysA
Classic Peer Persistence switchover example 52

Classic Peer Persistence recover
Recover synchronizes the delta changes from the target group to the source group.
A classic Peer Persistence recover operation:
Synchronizes the delta changes from the target to the source storage system for a classic Peer Persistence group.
Changes the classic Peer Persistence group Source role to Secondary-Rev.
Prevents hosts connected to the source system from having write access on the LUNs that are associated with the virtual volumes in
the classic Peer Persistence group.
Classic Peer Persistence recover 53

Classic Peer Persistence recover example
sysA Source, primary, read/write access Target, secondary-rev, read-only access

Replication direction Stopped sysB to sysA
Classic Peer Persistence recover example 54

Classic Peer Persistence reverse
Reverse changes the roles of the classic Peer Persistence Remote Copy group. Reverse brings the group back to a Normal DR state.
However, the original target system is now the source system.
A reverse operation:
Changes the Remote Copy group Source role from Secondary-rev to Secondary.
Changes the Remote Copy group Target role from Primary-rev to Primary.
Provides the host with read/write access to the volumes on the secondary (now primary) Remote Copy group.
Classic Peer Persistence reverse 55

Classic Peer Persistence reverse example
The following example shows the state of sysA (source) and sysB (target) before and after a reverse for a classic Peer Persistence
configuration.

sysA Target, secondary-rev, read-only access Target, secondary, read-only access
sysB Source, primary-rev, read/write access Source, primary, read/write access
Replication direction sysB to sysA sysB to sysA
Classic Peer Persistence reverse example 56

In a classic Peer Persistence configuration, the LUN on both storage systems is assigned the same WWN. These physically separate
volumes with the same WWN allow a host to see the same LUN with different paths. So if a failover occurs, the host can continue its I/O
operations uninterrupted.
Failsafe is used to prevent the volumes from becoming writable on both systems simultaneously. Failsafe helps prevent data
inconsistency between primary and secondary volumes when the volumes have the same WWN. Failsafe can occur even in non-Peer
Persistence configurations, if the volumes have the same WWN.
For example: The primary storage system fails (loses power, crashes, or reboots). The primary Remote Copy groups fail over to the
secondary storage system. When the primary storage system comes back up, the volumes in the primary groups are in a failsafe status
until the primary storage system determines the status of the secondary storage system.
For example: The primary storage system cannot communicate because the Remote Copy links and Quorum Witness communications are
down. A failover to the secondary storage system occurs and all volumes in the primary Remote Copy groups on the primary storage
system are placed into a failsafe status.
Failsafe in a classic Peer Persistence configuration 57

Nondisruptive failover in a classic Peer Persistence geo cluster environment
With classic Peer Persistence, you can federate your storage systems across geographically separate data centers. This intersite
federation of storage allows you to use your data centers more effectively. You can move applications from one site to another according
to your business need without any application downtime.
Nondisruptive failover is a high-availability configuration between two sites where:
Hosts are set up in a geo cluster configuration with access to storage systems on both sites.
Storage volumes created on the primary storage system are replicated to the secondary storage system using synchronous Remote
Copy.
Synchronous Remote Copy keeps the volumes synchronized at all times.
During a nondisruptive failover, host traffic to the failed (primary) storage system is redirected to the secondary storage system without
major impact to the hosts.
Nondisruptive failover in a classic Peer Persistence geo cluster environment 58

VMware vSphere Metro Storage Cluster (vMSC) is an example of a geo cluster, stretched cluster, or Metrocluster configuration. To
achieve high availability across host and storage system sites, host clusters use VM and/or cluster resource affinity and failover rules.
Hewlett Packard Enterprise supports vMSC uniform configurations. Uniform host access is a VMware-stretched cluster configuration
where each host can access storage resources available at both sites. It is geared towards protecting against a storage failure at a site.
Only a uniform configuration works with Active Peer Persistence or classic Peer Persistence to provide transparent failover without host
interruption.
Uniform host access provides:
Protection against storage failure
Active load balancing
The uniform host access configuration is a requirement to achieve the host transparent aspects of Active Peer Persistence or classic
Peer Persistence failover or switchover.
Figure 12: VMware vMSC certification—uniform host access
VMware vSphere Metro Storage Cluster configuration 59

Reference: Disaster recovery for SLD Remote Copy configurations
Reference: Disaster recovery for SLD Remote Copy configurations 60

SLD failover to a synchronous target
An SLD failover changes the secondary Remote Copy groups on the synchronous target to primary. When failing over to a synchronous
target, the failover operation responds differently based on the auto synchronize policy setting.
In this example, before the failover, SystemA is the primary system, SystemB is the synchronous secondary target, and
SystemC is the periodic secondary target. After the failover, SystemB is the primary-rev system and SystemC is the periodic
secondary target. Replication occurs between SystemB and SystemC .
When the synchronous target system becomes the failover system, the synchronous target system assumes the role of the primary
system. The host has read/write access to the volumes in the Remote Copy groups on the synchronous system.
Figure 3: Failing over to the synchronous target system
An Auto synchronize policy is not enabled failover:

Changes the SLD Remote Copy group Target role from Secondary, Secondary to Primary-Rev, Secondary ( SystemB and
SystemC ).
Provides the host read/write access to the source and synchronous systems ( SystemA and SystemB ).
An Auto synchronize policy enabled failover:

Changes the SLD Remote Copy group Source system to the synchronous target system ( SystemB ) and makes the role Primary.
SystemA is now a secondary system.
Keeps the DR state as Normal.
Provides the host read/write access to the source and synchronous systems ( SystemA and SystemB ).
SLD failover to a synchronous target 61

SLD failover to a synchronous target example
The following examples show the state of sysA (source), sysB (synchronous target), and sysC (periodic target) before and after a
failover.

sysB Target, secondary, read-only access Source, primary, read/write access
sysC Target, secondary, read-only access Target, secondary, read-only access
Group state sysA to sysB : Started sysA to sysB : Started

sysA to sysC : Started sysA to sysC : Backup
sysB to sysC : Backup sysB to sysC : Started
Replication direction sysA to sysB and sysA to sysC SysB to SysA and SysB to SysC

sysB Target, secondary, read-only access Target, primary-rev, read/write access
Group state sysA to sysB : Stopped sysA to sysB : Stopped

sysA to sysC : Stopped sysA to sysC : Backup
Replication direction Stopped SysB to SysC . Replication is stopped if you

selected Do not start groups after role reversal is
completed.
SLD failover to a synchronous target example 62

SLD failover to a periodic target
A failover changes the secondary Remote Copy groups on the periodic target to primary. When the periodic target system becomes the
failover system, the synchronous target system temporarily assumes the role of the primary system. Data is transferred from the
synchronous system to the periodic system. Then, the periodic target system becomes the primary-rev system. The host has read/write
access to the volumes in the Remote Copy groups on the periodic system.
In this example, before the failover, SystemA is the primary system, SystemB is the synchronous secondary target, and
SystemC is the periodic secondary target. After the failover, SystemC is the primary system and SystemB is the synchronous
secondary target. Replication occurs between SystemC and SystemB .
Figure 4: Failing over to the asynchronous periodic system
A failover to a periodic target:

Changes the SLD Remote Copy group Target role from Secondary, Secondary to Secondary, Primary-Rev ( SystemB and
SystemC ).
Provides the host read/write access to the source and periodic systems ( SystemA and SystemC ).
SLD failover to a periodic target 63

SLD failover to a periodic target example
The following example shows the state of sysA (source), sysB (synchronous target), and sysC (periodic target) before and after a
failover.

sysB Target, secondary, read-only access Target, secondary, read-only access
sysC Target, secondary, read-only access Source, primary-rev, read/write access
Group state sysA to sysB : Started sysA to sysB : Backup

sysA to sysC : Started sysA to sysC : Stopped
sysB to sysC : Backup sysB to sysC : Started. Stopped if you selected
completed.
Replication direction sysA to sysB and sysA to sysC SysC to SysA and SysC to SysB

sysC Target, secondary, read-only access Target, primary-rev, read/write access
Group state sysA to sysB : Stopped sysA to sysB : Backup

sysA to sysC : Stopped sysA to sysC : Stopped
Replication direction Stopped SysB to SysC . Replication is stopped if you

completed.
SLD failover to a periodic target example 64

SLD reverse roles after a failover
After a failover, a switch failover operation reverses the role of two target systems in an SLD group.
For example: A failover occurred from the source system to the synchronous target system changing the synchronous system role to
Primary-Rev. To change the Primary-Rev role to the periodic target system, perform a switch failover.
A switch failover operation:
Changes the Remote Copy SLD group Target role of the target systems. The primary-rev system becomes secondary and the
secondary system becomes the primary-rev system.
Provides the host with read/write access to the volumes on the primary-rev system.
SLD reverse roles after a failover 65

SLD reverse roles example
The following example shows the state of sysA (source), sysB (synchronous target), and sysC (periodic target) before and after
reversing roles. In this example, sysB and sysC reverse roles.
System or field name Before reverse (switch failover) After reverse (switch failover)
sysC Target, secondary, read-only access Target, primary-rev, read/write access
Group state sysA to sysB : Stopped sysA to sysB : Backup

sysA to sysC : Backup sysA to sysC : Stopped
sysB to sysC : Started. Stopped if you selected sysB to sysC : Stopped
completed during failover.
DR state Failover Failover
Replication direction sysB to sysC : Started. Replication is stopped SysC to SysB : Stopped
if you selected Do not start groups after role
SLD reverse roles example 66

SLD recover
Recovery reverses replication and synchronizes the delta changes from the target to the source storage system.
Manually recover a group if the auto synchronize policy is not enabled and the SLD Remote Copy group failed over.
A recover operation:
Synchronizes the changes from the target to the source storage system.
Changes the SLD Remote Copy group Source role to Secondary-Rev.
Prevents hosts connected to the source storage system from having write access on the LUNs that are associated with the virtual
volumes in the Remote Copy group.
Changes the DR state to Recover.
SLD recover 67
SLD recover a synchronous target example
recover. A failover occurred from sysA to the synchronous target sysB .
sysB Target, primary-rev, read/write access Target, primary-rev, read/write access
Group state sysA to sysB : Stopped sysA to sysB : Started

sysA to sysC : Backup sysA to sysC : Backup
sysB to sysC : Started. Stopped if you selected sysB to sysC : Started
completed during the failover.
Replication direction sysB to sysC : Started. Replication is stopped SysB to SysA and SysB to SysC : Started.
if you selected Do not start groups after role Replication is stopped if you selected Do not start
reversal is completed during the failover. groups after role reversal is completed.
SLD recover a synchronous target example 68

SLD recover a periodic target example
recover. A failover occurred from sysA to the periodic target sysC .
sysC Target, primary-rev, read/write access Target, primary-rev, read/write access
Group state sysA to sysB : Backup sysA to sysB : Backup

sysA to sysC : Stopped sysA to sysC : Started
sysB to sysC : Started. Stopped if you selected sysB to sysC : Started
completed during the failover.
Replication direction sysC to sysB : Started. Replication is stopped SysC to SysA and SysC to SysB : Started.
if you selected Do not start groups after role Replication is stopped if you selected Do not start
reversal is completed during the failover. groups after role reversal is completed.
SLD recover a periodic target example 69

SLD restore
A restore operation restores the SLD Remote Copy group to a prefailover state after the recover operation completes.
If an SLD Remote Copy group is manually recovered, the group must be restored manually.
A restore operation:
Changes the Remote Copy SLD group Target roles back to Secondary. The Source role changes to Primary.
Provides the host with read/write access to the volumes on the source system. The hosts connected to the target systems are read-
only.
The DR state returns to Normal.
SLD restore 70
SLD restore a synchronous target example
The following example shows the state of sysA (source), sysB (target), and sysC (target) before and after restore.
Example when DR is in failover state

sysA to sysC : Backup sysA to sysC : Started
sysB to sysC : Started. Stopped if you sysB to sysC : Backup
Replication direction sysB to sysC : Started. Replication is stopped sysA to sysB and sysA to sysC
Example when DR is in recover state
Group state sysA to sysB : Started sysA to sysB : Started

sysA to sysC : Backup sysA to sysC : Started
sysB to sysC : Started sysB to sysC : Backup
Replication direction sysB to sysA and sysB to sysC sysA to sysB and sysA to sysC
SLD restore a synchronous target example 71

SLD restore a periodic target example
The following example shows the state of sysA (source), sysB (target), and sysC (target) before and after restore.
DR is in failover state
sysC Target, primary-rev, read/write access Target, secondary, read-only access

sysA to sysC : Stopped sysA to sysC : Started
sysB to sysC : Started. Stopped if you sysB to sysC : Backup
Replication direction sysC to sysB : Started. Replication is stopped sysA to sysB and sysA to sysC
DR is in recover state
sysC Target, primary-rev, read/write access Target, secondary, read-only access
Group state sysA to sysB : Backup sysA to sysB : Started

sysA to sysC : Started sysA to sysC : Started
sysB to sysC : Started sysB to sysC : Backup
Replication direction sysC to sysA and sysC to sysB : Started. sysA to sysB and sysA to sysC
Replication is stopped if you selected Do not start
SLD restore a periodic target example 72

Reference: Disaster recovery for 3DC PP Remote Copy configurations
Reference: Disaster recovery for 3DC PP Remote Copy configurations 73

3DC PP switchover
A three data center Peer Persistence (3DC PP) switchover reverses the role of the synchronous systems in a 3DC PP group. The
switchover detects the 3DC PP configuration and states the secondary system is the one connected with a synchronous target.
Therefore, the secondary system is selected automatically for the operation.
Changes the Remote Copy 3DC PP group Target role of the target systems. The primary system becomes secondary and the
secondary system becomes the primary system.
Provides the host with read/write access to the volumes on the secondary system.
3DC PP switchover 74
3DC PP switchover example
switchover.

sysA Source, primary, read/write access Target, secondary, No read/write access
sysB Target, secondary, No read/write access Source, primary, read/write access
sysC Target, secondary, No read/write access Target, secondary, No read/write access
Replication direction sysA to sysB and sysA to sysC sysB to sysA and sysB to
sysC
3DC PP switchover example 75

3DC PP recover
A recover operation for a three data center Peer Persistence (3DC PP) configuration depends on the type of failure. A recover after an
automatic transparent failover synchronizes the delta changes from the synchronous target group to the source group.
Other disaster recovery scenarios require HPE Support. For example, if a system is physically damaged and must be replaced, contact
HPE Support. If both systems in the Peer Persistence configuration fail without a rolling failover to the tertiary system, contact HPE
Support.
3DC PP recover 76
3DC PP recover example
recover of an automatic transparent failover.

sysA Source, primary, read/write access Target, secondary-rev, read-only access

Replication direction Stopped sysB to sysA and sysB to sysC
3DC PP recover example 77

3DC PP reverse
Reverse changes the roles of the three data center Peer Persistence (3DC PP) group after recovering from an automatic transparent
failover. Reverse brings the group back to a Normal DR state. However, the original synchronous target system is now the source
system.
3DC PP reverse 78
3DC PP reverse example
reverse.

sysA Target, secondary-rev, read-only access Target, secondary, read-only access
sysB Source, primary-rev, read/write access Source, primary, read/write access
Replication direction sysB to sysA and sysB to sysC sysB to sysA and sysB to sysC
3DC PP reverse example 79

Related documentation
The following guides provide additional information for your Remote Copy solution. The guides are available at:
https://www.hpe.com/info/Primera600-docs
For HPE Primera OS:
Getting started with data replication using Remote Copy
Configuring and managing data replication using Remote Copy
Troubleshooting your Remote Copy configuration
Recovering from disaster using Remote Copy
Additional documentation
Installing and Updating HPE Quorum Witness for HPE Primera and HPE 3PAR located on HPESC.
TIP: To quickly locate a document on HPESC, enter the document title into the HPESC search bar.
HPE Primera Support Matrix located on SPOCK.
HPE Primera Peer Persistence/Active Peer Persistence/Active Sync Replication Host OS Support Matrix located on SPOCK.
Related documentation 80
Websites
General websites
Single Point of Connectivity Knowledge (SPOCK) Storage compatibility matrix
https://www.hpe.com/storage/spock
Storage white papers and analyst reports
https://www.hpe.com/storage/whitepapers
For additional websites, see Support and other resources.
Websites 81
Support and other resources
Support and other resources 82

Accessing Hewlett Packard Enterprise Support
For live assistance, go to the Contact Hewlett Packard Enterprise Worldwide website:
https://www.hpe.com/info/assistance
To access documentation and support services, go to the Hewlett Packard Enterprise Support Center website:
https://www.hpe.com/support/hpesc
Information to collect
Technical support registration number (if applicable)
Product name, model or version, and serial number
Operating system name and version
Firmware version
Error messages
Product-specific reports and logs
Add-on products or components
Third-party products or components
Accessing Hewlett Packard Enterprise Support 83

Accessing updates
Some software products provide a mechanism for accessing software updates through the product interface. Review your product
documentation to identify the recommended software update method.
To download product updates:
Hewlett Packard Enterprise Support Center
https://www.hpe.com/support/hpesc
Hewlett Packard Enterprise Support Center: Software downloads
https://www.hpe.com/support/downloads
My HPE Software Center
https://www.hpe.com/software/hpesoftwarecenter
To subscribe to eNewsletters and alerts:
https://www.hpe.com/support/e-updates
To view and update your entitlements, and to link your contracts and warranties with your profile, go to the Hewlett Packard
Enterprise Support Center More Information on Access to Support Materials page:
https://www.hpe.com/support/AccessToSupportMaterials
IMPORTANT:
Access to some updates might require product entitlement when accessed through the Hewlett Packard Enterprise
Support Center. You must have an HPE Passport set up with relevant entitlements.
Accessing updates 84
Remote support
Remote support is available with supported devices as part of your warranty or contractual support agreement. It provides intelligent
event diagnosis, and automatic, secure submission of hardware event notifications to Hewlett Packard Enterprise, which initiates a fast
and accurate resolution based on the service level of your product. Hewlett Packard Enterprise strongly recommends that you register
your device for remote support.
If your product includes additional remote support details, use search to locate that information.
HPE Get Connected
https://www.hpe.com/services/getconnected
HPE Pointnext Tech Care
https://www.hpe.com/services/techcare
HPE Complete Care
https://www.hpe.com/services/completecare
Remote support 85
Customer self repair
Hewlett Packard Enterprise customer self repair (CSR) programs allow you to repair your product. If a CSR part needs to be replaced, it
will be shipped directly to you so that you can install it at your convenience. Some parts do not qualify for CSR. Your Hewlett Packard
Enterprise authorized service provider will determine whether a repair can be accomplished by CSR.
For more information about CSR, contact your local service provider.
Customer self repair 86

Warranty information
To view the warranty information for your product, see the links provided below:
HPE ProLiant and IA-32 Servers and Options
https://www.hpe.com/support/ProLiantServers-Warranties
HPE Enterprise and Cloudline Servers
https://www.hpe.com/support/EnterpriseServers-Warranties
HPE Storage Products
https://www.hpe.com/support/Storage-Warranties
HPE Networking Products

https://www.hpe.com/support/Networking-Warranties
Warranty information 87
Regulatory information
To view the regulatory information for your product, view the Safety and Compliance Information for Server, Storage, Power,
Networking, and Rack Products, available at the Hewlett Packard Enterprise Support Center:
https://www.hpe.com/support/Safety-Compliance-EnterpriseProducts
Additional regulatory information

Hewlett Packard Enterprise is committed to providing our customers with information about the chemical substances in our products as
needed to comply with legal requirements such as REACH (Regulation EC No 1907/2006 of the European Parliament and the Council). A
chemical information report for this product can be found at:
https://www.hpe.com/info/reach
For Hewlett Packard Enterprise product environmental and safety information and compliance data, including RoHS and REACH, see:
https://www.hpe.com/info/ecodata
For Hewlett Packard Enterprise environmental information, including company programs, product recycling, and energy efficiency, see:
https://www.hpe.com/info/environment
Regulatory information 88
Documentation feedback
Hewlett Packard Enterprise is committed to providing documentation that meets your needs. To help us improve the documentation, use
the Feedback button and icons (located at the bottom of an opened document) on the Hewlett Packard Enterprise Support Center portal
(https://www.hpe.com/support/hpesc) to send any errors, suggestions, or comments. All document information is captured by the
process.
Documentation feedback 89

HPE - A00088924en - Us - HPE Primera OS - Recovering From Disaster Using Remote

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

HPE - A00088924en - Us - HPE Primera OS - Recovering From Disaster Using Remote

Uploaded by

Copyright:

Available Formats

HPE Primera OS: Recovering from disaster using Remote Copy

Part Number: 20-PRI600-RCRE-ED2

© Copyright 2019, 2022 Hewlett Packard Enterprise Development LP

UNIX® is a registered trademark of The Open Group.

Part number Publication date Edition Summary of changes

20-PRI600-RCRE-ED2 March 2022 2 Updated for HPE Primera OS 4.5

20-PRI600-RCRE-ED1 October 2021 1 Updated for HPE Primera OS 4.4

P23109-001 September 2019 1 Initial release

1 Recovering your 1-to-1, 1-to-N, or N-to-1 Remote Copy configuration

Recovering your 1-to-1, 1-to-N, or N-to-1 Remote Copy configuration 6

1. Stop the Remote Copy group on the source system.

Failing over a Remote Copy group manually 7

A manual failover has occurred.

3. Click Revert Failover.

Failing back after a failover of a Remote Copy group 8

Recovering a Remote Copy group 9

Restoring the direction of data flow in a Remote Copy group 10

Recovering your Active Peer Persistence or classic Peer Persistence configuration 11

Performing a switchover for Active Peer Persistence or classic Peer Persistence 12

3. Wait for the volumes to synchronize.

4. To reverse the replication direction, perform a reverse.

Recovering an Active Peer Persistence or classic Peer Persistence failover 13

The Auto synchronize policy is not enabled.

The reason for the failure is resolved.

1. Log in to the secondary (failover) storage system.

2. Recover the target system.

The Remote Copy group on SystemA is changed from primary to secondary-rev.

3. Reverse the role of the Remote Copy groups.

4. Wait for the volumes to synchronize.

5. (Optional) To change the groups back to the original configuration:

Both storage systems are ready to resume normal operations.

1. Log into the failover (secondary) system.

Recovering Remote Copy groups in a failsafe status 16

1. Log in to the failed and recovered (primary) storage system.

cli% setrcopygroup override <group_name>

cli% setrcopygroup override <target_name>

4. Start each Remote Copy group.

cli% startrcopygroup <group_name>

Overriding failsafe for Remote Copy groups in a failsafe status 17

Both storage systems are ready to resume normal operations.

2. Confirm the Remote Copy links are up.

3. Wait for the volumes to synchronize (the SyncStatus shows Synced ).

If synchronization completes, go to step 5.

If the volumes do not synchronize, go to the next step.

Where: <group_name> is the name of the Remote Copy group.

5. Wait for the Remote Copy groups to recover.

6. (Optional) To change a Remote Copy group back to the original configuration:

Recovering Remote Copy groups in a failsafe state with auto_synchronize on 18

Both storage systems are ready to resume normal operations.

2. Confirm the Remote Copy links are up.

If the links are up, go to the next step.

3. Recover the target group.

The Remote Copy group on SystemA is changed from primary to secondary-rev.

4. Wait for the volumes to synchronize (the SyncStatus shows Synced ).

5. Reverse the role of the Remote Copy group.

6. (Optional) To change the groups back to the original configuration:

Recovering Remote Copy groups in a failsafe state with auto_synchronize off 19

Recovering your synchronous long distance configuration 20

Failing over to the periodic target.

3. Select All targets.

4. Select Actions > Failover.

Failing over an SLD Remote Copy group manually 21

3. Click Switch failover.