vSphere manual Disaster Recovery failback when using VMware SRM

While many of you wonder why I am explaining manual Disaster Recovery failback when using VMware Site Recovery Manager where its an automated feature that is included in VMware vCenter Site Recovery Manager 5. Two main scenarios where this apply, the first one if you still using any vCenter Site Recovery Manager prior to VMware SRM 5. The other one if you need to break the replication then recover back without syncing back the changes that happened at the Disaster Recovery Site. In this scenario you won’t be able to use the automated failback feature of VMware vCenter Site Recovery Manager 5 as that sync the changes back to production in the process which you might not desire. For both of these scenarios the below steps become handy.

  1. Confirm Protected VMs recovered to DR Site are no longer being used and can be powered down.
  2. Confirm that you have an inventory of your VMs, DataStores, IPs, Network interfaces
  3. Power down the protected VMs in the DR Site.
  4. Perform a cleanup of the directory in the DR site that contained the placeholder VMs created during protection group creation in Protected site if placeholders exist.
  5. Delete earlier created Protection Groups and Recovery Plans.
  6. Connect to the vCenter Server in the protected site and remove all the VMs in the protected site that was recovered to the DR site from inventory.
  7. Connect to the vCenter Server in the DR site and remove all the VMs in the DR site that was recovered to it when the protected site failed over from inventory. (Only you need to remove it from inventory not from disk, in case you need to come back to it)
  8. Present the original LUNs back to the protected site as full read and write
  9. Right click the cluster where the the protected VMs reside in vCenter on the production side => Rescan for Datastores
  10. Go to each host configuration tab=> Storage. Then verify that all the datastores required are mounted.
  11. Add the VMs back to the inventory of the main site. Use the list created during the failover stage.
  12. If you see a small yellow warning on the VM  then right click it and open the console on that VM. Then from the dialog choose “I moved it” and hit OK
  13. Reconfigure the VMs Network interfaces (Port groups) in case they are connected to a Distributed Switch. Note: Virtual Machines vDS Network Interfaces configuration in VMX file is lost upon removing it from inventory
  14. Establish replication from the protected site to the DR site.
  15. Recreate all the protection groups and recovery groups again.
  16. Run a failover test & clean up to ensure all is back in place.

I hope this help one execute or document the procedure as required.

One Response to 'vSphere manual Disaster Recovery failback when using VMware SRM'

  1. CR7 - November 29th, 2014 at 2:25 pm

    Hi EIAD,

    I couldnt figure out where to post this doubt of mine, so im just posting it here.Please help out if you can find time.

    I am getting following errors while trying to move backup to take :-
    dsmc ar -archmc=AMS_ARCHIVE -su=yes “/prd00/u05/bkup/XPRD/export/*.gz”
    IBM Tivoli Storage Manager
    Command Line Backup-Archive Client Interface
    Client Version 6, Release 2, Level 2.0
    Client date/time: 11/29/14 13:54:51
    (c) Copyright by IBM Corporation and other(s) 1990, 2010. All Rights Reserved.

    Node Name: ODCAP
    Session established with server TSMPD03: AIX
    Server Version 6, Release 2, Level 6.0
    Server date/time: 11/29/14 13:54:51 Last access: 11/29/14 13:19:38

    ANS1103E Invalid management class entered

    Following are the details of management class :-

    tsm> query mgmtclass -detail
    Domain Name : UNIX
    Activated Policy Set Name : UNIX
    Activation date/time : 10/17/14 12:18:01
    Default Mgmt Class Name : UNIX_MGMT
    Grace Period Backup Retn. : 30 day(s)
    Grace Period Archive Retn.: 30 day(s)

    MgmtClass Name : UNIX_MGMT
    Description :
    Space Management Technique : None
    Auto Migrate on Non-Usage : 0
    Backup Required Before Migration: YES
    Destination for Migrated Files : SPACEMGPOOL
    Copy Group
    Copy Group Name……..: STANDARD
    Copy Type…………..: Backup
    Copy Frequency………: 0 day(s)
    Versions Data Exists…: 2 version(s)
    Versions Data Deleted..: 1 version(s)
    Retain Extra Versions..: 30 day(s)
    Retain Only Version….: 60 day(s)
    Copy Serialization…..: Shared Static
    Copy Mode…………..: Modified
    Copy Destination…….: DISKPOOL
    Lan Free Destination…: NO
    Deduplicate Data…….: NO

    Could you please help out?
    Cheers !! 🙂

Leave a Reply