In my last post about Cohesity, I showed you how to set up replication between Cohesity clusters so that you could have DR using an off-site Cohesity cluster. Today I will walk through how that actual recovery might happen. You can watch the video of the process here on YouTube. We think of DR planning as being protection against major events, floods, fire, tornados, and the like. The reality is that most DR activities are more mundane. Real disasters are infrequent, and a DR plan is mostly insurance that we pray we never need to use. Often the DR environment is also the test and development environment, and the usual recovery is to bring up an isolated copy of production. Using the DR environment for testing delivers additional value from what would otherwise be expensive idle equipment. Each test also validates that parts of our DR plan will work if a disaster does occur.
Disclosure: This post is part of my work with Cohesity.
So, what is the process to recover a replicated backup set to our DR site? It is essentially a normal Cohesity recovery to a new location. Almost as simple as a recovery to the original location we do need to specify where in the vSphere inventory we want to restore.
I have my Bronze protection policy setup to replicate backups to my DR cluster and have this policy applied to a protection job called “C” which protects two VMs: C-DC and C-FS. At the DR cluster you can see the protection job and its status at the last run, note that the protection job is inactive at the DR site, it is active at the production site where the protected VMs run.
We start by clicking the Recover button at the DR site and choosing to recover VMs.
Then we search for the VMs we want to recover. I used the protection job name and just selected the protection job, which automatically added both the VMs.
Now there were more questions to answer. The default is to restore the most recent protection point, in my case 8:43 pm on the 5th. Since I was recovering at a remote location, the next default was to recover to a new location. I did need to select the “source” which is really the destination as it is my DR vCentre server, then the inventory location and datastore for the recovered VMs.
I did change the default network configuration, choosing to connect the VMs to an existing port group at the DR site. If the port group has just been created you may need to “refresh” the source, look in the Sources page, on the Protection menu. I chose my Net900 portgroup, as well as the option to preserve MAC addresses at the recovery. Tread carefully with preserving MAC addresses; you do not want multiple VMs with the same MAC address in the same network. I also selected to automatically power on the restored VMs as I wanted service up as fast as possible.
A couple of minutes after I clicked Finish my DR vCenter showed running VMs being migrated from the Cohesity hosted recover datastore to the Host0-SATA datastore that I chose for the destination. Then a little while later, the VMs finished migration, and the recovery datastore was removed. Now I had a complete copy of my two production VMs in an isolated network at my DR site.
As is usual with Cohesity, I was pleased with the quick and easy the setup of a reasonably complicated environment. One of the cool parts here is that I did not need the same storage at my two sites. I could have a production site with a storage array and DR site with only local storage. I could have a single ESXi running Cohesity virtual edition at each branch office and provide DR in my HQ for all my branch offices. The requirement is to have Cohesity at both sites and replicating using those Cohesity clusters over normal TCP networks.
For a wider view of Data Protection and Disaster Recovery, you might want to take a look at this on-demand webinar hosted by the always awesome Theresa Miller.
© 2019, Alastair. All rights reserved.
RSS - Posts