Once the volumes have been successfully recovered into a pod, the pod can be immediately re-stretched if desired to a 2nd array. This can be done before or after a reprotect operation.
If the pod was originally stretched it is recommended to re-stretch it prior to reprotection, to ensure the highest protection level provided by ActiveCluster, enable ActiveCluster as soon as possible.
To start a reprotect, click Reprotect.
Complete the wizard to confirm the reprotection.
The process follows these rules:
- The SRA will look for the original source volumes on the asynchronous target array; if it cannot find it, the SRA will setup a new protection group on the pod-owning FlashArray-see below for details. The source volume is identified via the volume name-so if it has been renamed on the source the lookup will fail
- Protection groups on the asynchronous target array that include the original source volume will be created on the pod-owning FlashArray, even if they do not have replication enabled and/or replicate to a different array
- Protection group name matching is not case-sensitive. So if the asynchronous target array has a protection group called srm-pg and the pod-owning FlashArray has one called SRM-PG, they will be considered the same and no new group will be created
- For protection groups created by the SRA, the SRA will match the replication and local snapshot policy
- Protection groups that are created by the SRA during reprotect will only add the originating FlashArray as a replication target, no matter how many targets were in the original protection group. If you would like the created protection group to also replicate to other arrays, add them manually as targets later
- If the original source volume on the asynchronous target array is in more than one protection group, the SRA will re-create all protection groups on the pod-owning FlashArray
- If a protection group with the name already exists on the pod-owning FlashArray, the SRA will not re-create the group and will put the volume in that identified group
- If a pre-existing protection group policy name does not match the original source protection group policy, it will still be used. The SRA will not update the identified pre-existing protection group with the policy on the original array
If the SRA cannot find the original source volume (and therefore cannot identify the correct protection groups) or those volumes are in no protection groups on the asynchronous target array, the SRA will instead create a protection group with the default replication policy with the name PureSRADefaultProtectionGroup replicating back to the original array.
This protection may be edited and changed (or even removed) as desired afterwards. Ensure that the desired volumes are still replicated by a protection group.
The reprotect operation will rename the volume on the target array to remove the applied suffix of -puresra-failover.
If failures occur, the Force Cleanup option will become available-it is highly encouraged to not resort to that option immediately. It is advised to attempt figure out and resolve the underlying problem and re-run the reprotect without Force Cleanup selected until successful.
The main reasons that a reprotect could fail are often in the VMware environment (placeholders aren't there, mappings are incorrect or missing, etc). Though some FlashArray failures can cause this too:
- Replication connection does not exist back to the array. If so, re-create this connection
- Array managers are configured incorrectly
- Original source volume was renamed. It should be in the form of <volume name>-puresra-demoted. If it is not, rename it back. You will see an error like: SRA command 'prepareReverseReplication' failed for device '<volume name>'. Cannot find the volume <volume name> on the array <arrayname> Please make sure that replication setup is correct". If it fails in the prepareReverseReplication phase, likely the source volume has been renamed manually or destroyed. Either rename it back, or if it is gone, run an SRM SRM User Guide: Discovering Replicated Devices with the FlashArray SRA and then re-attempt the reprotect without force cleanup checked. Only if that fails, should you then retry with force cleanup checked
- The source pod was renamed. If so, rename it back to the original name, or remove the SRM protection group and create a new one
- The pod is stretched across two arrays. Unstretch it from one of the arrays. If you do not want to do so, remove the SRM protection group and create a new one
- Target volume was renamed. It should be in the form of <volume name>-puresra-failover. If it is not, rename it back. You will see an error like: SRA command 'reverseReplication' failed for device '<volume name>'''. Cannot find the volume '<volume name>' on the array <arrayname>
- If this is the case, fix the name of the volume AND ensure that the original volume is still in a protection group replicating to the target. The reprotect operation will have removed it from any replication groups at this stage causing device discovery to fail
- A volume exists with the original name but no suffix. If the original volume was srm-DS1 and it was failed over to the 2nd array, the failover volume will be called srm-DS1-puresra-failover. If there is a volume on the failover array called srm-DS1 already the initial recovery will not fail, but the reprotect will as it will try to rename the volume from srm-DS1-puresra-failover to srm-DS1 which will fail because there is already a volume with that name. While this is unlikely to occur, it could. You will see an error upon reprotect like: Failed to reverse replication for device 'peer-of-53f027a7-828d-4b4d-a3a8-d4b2c8364507:srmDS-08'. SRA command 'reverseReplication' failed for device 'peer-of-53f027a7-828d-4b4d-a3a8-d4b2c8364507:srmDS-08'. Could not rename failed over volume srmDS-08 to peer-of-53f027a7-828d-4b4d-a3a8-d4b2c8364507:srmDS-08 on array flasharray-m20-1. Note that the volume might be in the destroyed volume folder awaiting eradication if it is not visible