Can Your Business Afford Downtime or Data Loss?

July 15, 2015   //   Security, ,

Mitigate downtime and restore data with disaster recovery and high availability systems.

Most businesses today run 24/7 and can’t afford server, appliance or system downtime. Having a disaster recovery or high availability system is necessary to mitigate the risk and impact to a business during such a time. Since these two terms are often confused, let’s first define them.

  • High availability: A secondary server, appliance or system is in place that can immediately take over if a primary system becomes unavailable (with little to no downtime).
  • Disaster Recovery (DR): A system or process to restore a server or system in the event of an unexpected event. There is downtime experienced and the process to restore service typically requires a human decision to initiate.

Let’s Start with Disaster Recovery

I typically encourage clients to start with disaster recovery. The ability to restore data or recover services should be foundational to any IT organization. Today, most organizations cannot afford to be without priority one applications for more than an hour.

The good news is there are many options that can simplify the implementation of a Disaster Recovery plan and keep costs reasonably low while remaining flexible in the levels of expectations around recovery time.

If your organization already has a Disaster Recovery plan, it’s importantly to periodically address these questions:

  • When was the last time it was reviewed?
    • Is the Disaster Recovery plan’s server inventory accurate?
    • Are system dependencies clearly defined?
    • Is the plan updated when new servers are provisioned?
  • Has it been reviewed by other business units and agreed upon that it meets the business’s needs?
  • How rigorous has testing been?
    • Are business units included in testing and determining a test’s success?
    • How often are tests being performed?
    • Are the Disaster Recovery testing procedures well documented?

If your organization doesn’t have a Disaster Recovery plan, you need to ask:

  • Is the business in agreement that no formal Disaster Recovery plan is needed?
  • Has a business impact analysis been performed to help determine what the impact of downtime is?
  • What is the current level of certainty the business can recover from a disaster?

Implementing a Disaster Recovery Plan

Your Disaster Recovery plan will be successful when you treat it as an ever-changing necessity that is part of day-to-day process. For example, part of the server provisioning process should address the Disaster Recovery updates needed. Here are some steps to help you get started:

  1. Focus initial efforts on clearly defining the business requirements, not the tools. Select a tool that addresses the business requirements; going the other direction can cause complications down the road.
  2. Determine who will be responsible to test all services during a Disaster Recovery incident. This needs to include application owners and process owners.
  3. Instead of looking at Disaster Recovery using a “server by server” approach, map out the services IT is responsible to deliver and which servers are needed within each service. This approach can help move the conversations along with the other stakeholders and simplify discussions on recovery time objective, recovery point objective, etc.
  4. Discuss the priority of servers, services and applications. During the first iteration of a Disaster Recovery planning project, most organizations I’ve worked with will classify nearly all of the services as “priority one.” While they are all important, when putting a formal Disaster Recovery plan together, it’s critical to specify which servers and services take priority.

There are several options available for organizations to get a Disaster Recovery strategy in place, including cloud-based options that do not require a capital investment in additional hardware.

Do You Need High Availability?

Even though Disaster Recovery is often confused with high availability, highly available systems tend to be completely different conversations than Disaster Recovery. There are many factors to consider when leveraging highly available systems including: additional licensing requirements, more sophisticated systems management/maintenance procedures, available data center capacity, etc. You should also consider:

  • Utilizing virtualization for their native high availability features is a start, but going deeper into enterprise application’s native availability features (like Exchange DAG, SQL AlwaysOn Availability Groups, file replication, etc.) is a critical component of high system availability.
  • Not all applications will require or support high availability configurations. Clearly document which applications should be highly available, highly recoverable, or both.
  • IT should get input from other business units to determine what level of protection is truly necessary to the business. For example, active/active configurations may have different cost structures than active/passive.

The above factors are just some of the considerations to be addressed during Disaster Recovery or availability conversations. SWC can help your organization with service delivery strategy – Disaster Recovery or Business Continuity planning as well as system high availability architecture design, implementation, and performing functional testing to ensure service recoverability.

Take the first step towards mitigating downtime or restoring data loss. Call us at 630.572.0240 or email one of our subject matter experts.