Keeping the business going and providing a high availability of all connected systems is not at all a trivial task. Furthermore, it is cost intense.
Preparing for High Availability (HA)/Business Continuity is a bit like having an insurance for an event, that many hope will never happen. This is why in many organizations there it is quite difficult to find the right time to start planning (if there is no HA strategy in place yet).
Plus, when you actually start working on it, the planning process is not that simple. What do you anticipate? What events of failed connections, servers or storage you want to avoid?
Essentially, the question is how to create an environment which enables to smartly deal with outages? First of all beware of the case-tricks in continuity planning. Here come the most important 10 mistakes based on an article by TechTarget.
1. Don’t think high availability equals DR.
There still is a need for continuity planning in case of a downtime. Moreover high availability is not always appropriate to all your workload. Often, only parts of the data really needs to be made available continously. Beware of the high costs of high availability.
2. Don’t try to make all applications fit one DR approach.
A one-size-fits-all strategy is not always the best solution. Again, consider the various types of data you deal with and try to customize to specific workloads. Not all data needs disk to disk replication, mirroring or other methods to protect the data and provide availability.
3. Don’t try to back up everything.
Save some costs and precious backup time in separating archive data from production data. Data which is not going to change any more does not need to be updated with the same frequency as actual data. Ensure to diminish duplicate content from your repositories.
4. Don’t overlook data that’s not stored centrally.
Generally, not all the data is stored in a central repository. In times of BYOD (Bring your own device) an increasing amount of data is loacted on these devices. Make sure to have an appropriate approach to cover distributed data, i.e. with a specialized cloud service.
5. Don’t mismanage data and infrastructure.
Know which of your data is important and prioritize data restoration according to your business workflows. Visualize the fluctuations in the availability of your infrasctructure and closely monitor systems in order to react well-directed.
6. Don’t try to duplicate equipment configurations at the recovery site.
Normally only a subset of your system needs to be re-instantiated after a disruptive event. Identifying relevant components is essential to set up a Minimum Equipment Concept (MEC), which can run on either virtual or physical hosts.
7. Don’t forget to fortify your WAN connections.
Be aware to have enough network connection in case of a disruptive events and the resulting use of recovery timeframes. Make sure that your WAN is properly configured to manage the additional workload caused by the processes of recovery systems.
8. Don’t put too much trust in a cloud provider.
If you continuously have moved data to a backup cloud you might be suprised about the accumulated masses and the amount of resouces it might take to play it back in case of a disaster recovery. If you want to use your cloud back up as a ‘hot-site’, make sure to know and trust the company.
9. Don’t let app designs foil DR.
Disaster recovery planning is not a passive task. The planning should go hand in hand with app designers in order to come up with a proper use of resources within a given infrastructure. Make sure, that resiliency and recoverability is built into the applications.
10. Don’t forget to follow the money.
Base your Disaster Recovery plan on business value. Show how your DR reflects the target to minimize the costs without sacrifizing the aim to protect data and secure business continuity. Point out the improved productivity and reduced investment risks enabled by the plan.
Keep in mind: The biggest amount of costs spent for data protetion is not for storage, application re-instantiation or network re-routing; it is the long-tail-cost for testing. So, it is important to create a system that can be tested as part of day-to-day operations rather then formal testing.
Image Source: flickr



