Reprotect

A reprotect operation automates the replication of failed over volumes back to the original FlashArray. In order to run reprotect, a fully successful recovery must occur. If the disaster recovery operation was executed and skipped multiple steps due to failures, a reprotect might not be possible. In this case manual reprotection might be required--which is essentially the same process as setting up replication for the first time. If a reprotect fails, try again with the Force Cleanup option checked (it will only appear if a reprotect has failed once).

1. Sets up replication on the FlashArray(s) that are now running the VMs
2. Reverses the SRM protection groups and recovery plans
3. Initiates a synchronization of the data.

   To start a reprotect, click on the desired SRM recovery plan and click Reprotect.

   

   Confirm the action and click Next, then Finish.

   

   The FlashArray will then look for the FlashArray protection group or groups of the source volume.

   For ease of explanation, FlashArray A will be the array that was failed over from and FlashArray B will be where the volume was failed over to and where the VMs are currently running before reprotection.

   The process follows these rules:

4. The SRA will look for the original source volume on FlashArray A, if it cannot find it, the SRA will setup a new protection group on FlashArray B--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 FlashArray A that include the original source volume will be created on FlashArray B 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 FlashArray A has a protection group called srm-pg and FlashArray B 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, it will match the replication and local snapshot policy.
   • Protection groups that are created by the SRA during reprotect will only add the original 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.
5. If the original source volume on FlashArray A is in more than one protection group the SRA will re-create all protection groups on FlashArray B.
6. If a protection group with the name already exists on FlashArray B 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

   Note:

   Once the protection has been re-created on the now production side, the original source volume(s) will be removed from protection groups that replicate to the now production array. If the volume is in protection groups that do not replicate to the now production array, the volume will be left in those.

   If the SRA cannot find the original source volume (and therefore cannot identify the correct protection groups) the SRA will instead create a protection group with the default replication policy with the name PureSRADefaultProtectionGroup replicating back to the original array. You may edit and change (or even remove) this protection group as desired afterwards. Just ensure that the desired volumes are still replicated by a protection group.

   

   The reprotect operation will then complete swapping directions of the SRM objects and reconfiguring protection of the virtual machines in the recovery plan.

   

   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.
   • 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 you cannot see it.