Disaster Recovery Done Wrong! PART Two
Greetings, Manchester business owners! Here is the second installment of our focus on the common pitfalls of Disaster Recovery planning. Every company presents unique challenges that must be answered with uniquely tailored solutions, which is why working in collaboration with an experienced IT support company like Everything Tech pays dividends when a crisis inevitably rears its head.
In this instalment, we continue to look at the mistakes that many businesses make when planning safeguards against risks to business continuity.
Recovery Time Objectives: How much downtime can you afford?
How soon do you need to have your systems up and running? Or to look at it another way: how much does an hour of downtime cost your business? This figure puts your RTO (Recovery Time Objectives) in perspective i.e. if downtime is likely to only cost you £100 an hour, you can probably afford an RTO of several hours whereas if downtime can cost you £10,000 an hour (which could be the cost of the loss of a lifetime’s worth of one person’s custom, remember) you’re more likely to view a very short recovery time as being critical to your business.
Many businesses set RTOs that just aren’t attainable, failing to account for things like preparation time, immediate access to IT staff (whether internal or external IT Services & support) and testing to gauge the severity and reach of the issue.
When formulating a Disaster Recovery plan, you should set Recovery time Objectives based on your actual business continuity requirements. These can be derived through detailed ‘business impact analysis’. When testing your disaster recovery plan, measure its success in Recovery Time Actuals (RTAs) which take into account any activities that wouldn’t normally be part of day-to-day business operations.
Contingencies at every step
Another mistake that we see made time and time again is failure to incorporate contingencies into each step of the disaster recovery plan. As the old saying goes: "Anything that can go wrong, will go wrong." The job is only half done if, when you plan for an IT disaster, you do so whilst assuming that all of the necessary resources and personnel will be available to you. For each stage of the Disaster Recovery plan, consider and document what should be done if a resource, system, piece of kit or software cannot be used and also if the person responsible or to be consulted for that stage of the plan in not available. The main thing to take away from this is that you do indeed need to have a backup plan for your backup plan!
Don’t let your recovery site lag behind
You may have a recovery website set up in case your primary site goes down, but in an attempt to minimise costs for infrastructure that is not used regularly, businesses often overlook software licensing for the backup site. Several software vendors do allow for passive licensing for inactive sites but you cannot take this for granted. The site may be useless if its integrated software isn’t operational because of licensing issues.
Limited storage, processing and hosting resources with a recovery site can also be problematic for business continuity; for instance, if the customer/traffic capacity of your backup site hasn’t grown in line with your main website (which has been steadily evolving to cope with increased load and demand). You should test the backup site under an authentic, up-to-date workload for a reasonable time. It’s very important to emulate how the recovery site will respond in the event of a real-life disruption (on a busy day!). You need to ensure that the recovery site has adequate infrastructure resources or, better still, that resources can be quickly accessed and added via an enterprise cloud solution, such as Microsoft Office 365.
EverythingTech offer Disaster Recovery, IT Services and Support in Manchester. We hope you’ve enjoyed this 2 part article and found it very useful. If you’re interested in finding out more about how Everything Tech can help with your Disaster Recovery planning, please get in contact with our team.