Recovery from an Asynchronous Site to a Pod-based Site

User Guides for VMware Solutions

Audience
Public
Content Type
User Guides
Source Type
Documentation

Site Recovery Manager offers two main modes of failover: Planned Migration and Disaster Recovery. A planned migration will fail if any problems are encountered at the source or target site. A disaster recovery operations will tolerate up to a full failure of the source site resources and still recover the virtual machines. It is recommended to run a planned migration operation if possible, as this will ensure the cleanest failover of the environment. Furthermore, if a disaster recovery event is run, it is likely that manual cleanup of the source site will be required once resources are back online.

The high-level process of a recovery is:

  1. Issue a synchronization of the relevant FlashArray volumes to the target
  2. Shutdown the production side virtual machines, unregister the VMs, and unmount the datastores
  3. Synchronize the relevant FlashArray volumes again to the target
  4. Create new FlashArray volumes from the replicated snapshots on the target array
  5. Move the volumes into the pod
  6. Connect the volumes to the appropriate hosts and/or host groups
  7. Rescan the target cluster(s)
  8. Resignature and mount the datastores
  9. Power-on the VMs and configure them according to the recovery plan

    To start a recovery, click on the Run button on the recovery plan.

    Confirm the type of the recovery and the details of the operation and click Next then Finish.

    Note:

    If the pod is stretched, the synchronization will fail. Unstretch the pod manually and try again.

    The data will be synchronized twice to the target FlashArray. Once before the VMs are shutdown, and once after.

    On the corresponding FlashArray protection groups on the array currently hosting the pod, you can see a new protection group snapshot created for each synchronization with a name of a random UUID and "-puresra".

    The second point-in-time will likely be the one used for recovery, but if a new point-in-time is created between the second synchronization and the subsequent step, the latest one will be used.

    Upon the step called Configure recovery site storage, the replicated snapshots will be copied to new FlashArray volumes on the target FlashArray.

    The volumes will be named with the same name as their source with a suffix of -puresra-Failover added. If the original volumes are still there with a suffix of "-puresra-demoted" those existing volumes will be re-used.

    The original source volumes will be disconnected from their hosts and also renamed at this point. The SRA will add the suffix of -puresra-demoted to those volume names.

    It is strongly recommended to not delete or rename the source volumes (the volumes with -puresra-demoted in the name) after a failover and prior to a reprotect. If a volume is renamed during this windows, the SRA will not be able to find the original protection of the source volumes; it will just create a default protection group called PureSRADefaultProtectionGroup with replication enabled back to the source array.

    The device discovery screen will show the device pair(s) as Failover Complete.

    The recovery volumes are connected to appropriate hosts or host group on the recovery site and SRM will resignature and mount them. The resignature process will add a name prefix to them of snap-XXXXXXXX. SRM can be configured to automatically remove the suffix through advanced configuration documented SRM User Guide: Site Recovery Manager Advanced Options.

    The virtual machines will be registered, configured, and then powered-on according to the recovery plan.