The ability for a business to recover from a disaster—whether natural, technological, or human—is essential for ensuring business continuity and survival.
Disaster Recovery (DR) involves a set of policies, tools, and procedures to enable the recovery or continuation of vital technology infrastructure. in the event of a disaster the business can come back online at some point in the near future. In my experiences, enterprises often struggle with many things as it relates to disaster recovery, including budgets, to successful deployment, and routine testing. It’s the one thing that gets put on the backburner or dropped from the budget when it’s the most important thing to making sure the business can continue no matter what. It’s a business insurance policy for enterprise data. Just because your data is replicated or backed up as an insurance policy, poor DR planning or lack of testing may mean the difference between a prolonged outage or no business disruption. Could your enterprise even go on without its data? I suspect not.
Real World Summary
The challenges enterprises face when planning and deploying their disaster recovery strategy are real. They involve being able to replicate your entire or most of your enterprise data to a different location ensuring that your enterprise can be brought online no matter what the cause of disaster. No longer limited to physical architecture, the cloud works as a fantastic way to make this happen effectively without the heavy lifting that goes into a physical deployment architecture. Cloud is also more advantageous from the cost and resources perspective. With cloud, your only spend is cloud storage until the system is brought online, then at that point you pay for compute.
Imagine this, and yes this happened. A large subset of your storage in your SAN hard drives fail, and even with a DR plan and testing the failover process only worked for some applications. In this case the email application I supported came online successfully in DR, and the virtualization application I supported came online with manual intervention as planned. However, there were applications that didn’t come back at all, but where the proper planning occurred there were no surprises.
Lessons learned? Take the time to design and architect the plan, activate it for testing during planned time windows, and test the user experience during failover and failback for the win!
How Cohesity can Help
The answer is quite simple and comes down to these simple elements: design planning, validation testing, and execution of your disaster recovery plan leveraging Cohesity Runbook.
1) Design Planning:
With Cohesity Runbook the design planning is done through an automation and orchestration interface that is visual and simple to use. You can drag and drop VMware virtual machines, add startup delays, and add script executions to spin up your production environment in the AWS cloud or for failover to your VMware vSphere environment. Runbook simplifies the process for the enterprise administrator in a much-needed way.
2) Validation Testing:
With the simple click of a button, validation testing begins behind the scenes without user impact. All of the VMs associated with your runbook, including startup delays, are verified, visually confirmed, and tested before a disaster recovery event occurs.
3) Execution:
When a DR event occurs, just simply use the execute button to initiate the failover, to seamlessly and efficiently bring your enterprise back online, and failback whenever your disaster situation is complete.
Cohesity Runbook can help you with proper DR design planning and validation testing your enterprise. But that’s not all, Cohesity also helps you address this through disaster recovery replication, failover, failback, and keeping your recovery times in check. The key benefit being that your enterprise will be ready to stay online regardless of the situation or unforeseen disaster that lies ahead.
