By Darren Beale

If you have a web application that is critical to your business, it’s important to understand how to mitigate the risks of a disaster happening. Applications will, sooner or later, run into problems. You want to do enough due diligence to make sure your company will not be too negatively impacted by application downtime.

Disaster recovery planning (DRP) means planning for unexpected things that may impact a business. For companies using an outsourced web development/maintenance team, it means having a plan in place to deal with many of the common things that can go wrong with applications.

In this article, we’ll discuss why such contingency plans are so important and how you can better understand how disaster recovery is being implemented for your application.

Why Is Web Application Disaster Recovery Planning Necessary?

If your company uses an online application, and that application’s downtime will affect your business, disaster recovery plans are necessary. Application downtime can mean:

  • Economic pain: You’ll suffer the loss of immediate and future sales, plus loss of leads.
  • Reputational pain: Being non-functional looks unprofessional and can hurt your reputation. If that problem lasts a while and people really start to notice, it can hurt a lot.

Depending on how critical it is to your business, a non-functioning application might mean lawsuits, or even the end of your business. Chances are you are already aware of the negative effects of problems with your application, so we’ll stop with the doom and gloom.

Problems Will Happen

Problems leading to application downtime can include:

  • Hardware problems (e.g., a server going down)
  • Application code problems
  • Dependency problems (i.e., necessary programs and installations not being present)
  • Human error (e.g., an employee deletes a database)
  • Human maliciousness (e.g., hacking or sabotage)
  • Natural, random disasters (e.g., a building being destroyed, or a developer becoming ill)

With the amount of things that can go wrong, it is only a matter of time until you deal with a significant problem with your app. It is smart, indeed a no-brainer, to come up with detailed disaster recovery plans. But you’d be surprised how often companies are taken by surprise and don’t have plans in place.

How Important Is Your App?

When coming up with disaster recovery plans, the first question you must get clear on is:

How much application downtime is allowable?

You must decide how mission-critical your application is to your business. Can it be down for an hour without a serious impact? A few hours without a serious impact? Or if it’s down for an hour or a few hours is that completely unacceptable in terms of financial loss?

There are numerous types of solutions for minimizing downtime and maximizing availability. Some of them are very complex and very expensive. How extensively you want to pursue optimal availability will depend on how important your app is. If it is very important, and the downsides to being down are huge, then you will obviously be motivated to spend lots of money on the problem.

For many businesses, being offline for a few hours will have some negative impact, but not such a negative impact that they are motivated to spend thousands of dollars per month. If you decide that being down for a few hours is acceptable in the event of an unexpected disaster, then many problems become more manageable.

Who’s Responsible for Disaster Recovery Planning?

Probably you.

If you are the manager, don’t make assumptions about who’s responsible for making plans or for implementing those plans when disaster strikes.

If you’ve hired an outside dev/maintenance team, there’s a good chance that disaster recovery procedures will be outside their scope.

Same for hosting companies. You will want to get clear on what responsibilities your hosting company has in the event of a server problem. Don’t assume that they will be of help in troubleshooting the problem, or even in getting the application back up and running. Many hosting companies have SLAs that only require them to set you back up with a new working server and you will be required to get your application back up.

Usually, it will fall to the internal operations manager to oversee disaster recovery procedures.

That being said, it’s a great idea to ask advice from your hosting provider and your development or maintenance team on what contingency plans they have in place, and what they recommend you to do.

Too busy to do this yourself?

We can help you quickly put a Disaster Recovery Plan in place. For a fixed fee we’ll do all the leg-work and give you peace of mind that there’s a plan in place should the worst ever happen.

Creating A Disaster Recovery Plan

At its simplest level, a DRP will tell you this: When such-and-such problem happens, who gets called and what do they do? A DRP helps you:

  • Avoid panic (because panic will cause more problems)
  • Know specifically who is in charge of specifically what

Some elements you want to include in your DRP:

  • Different plans for different types of problems
  • Contact information for everyone integral to recovery
  • Location of vital information, such as server passwords
  • Instructional playbooks for external teams and companies
  • Guides for testing the DRP intermittently

Questions for Your Hosting Company

Some questions you might ask your hosting company to get clear about how much they’ll be able to help you when a problem arises:

  • What exactly do they do in the event of a server going down or other problems? (As we said, don’t assume they will help you get your application running again.)
  • What hours of the day can you call them for help?
  • How often are back-ups done of file systems and of the databases?
  • For databases, are there slave/mirror versions saved, to ensure redundancy?
  • For a large server outage, are there other servers they can get you up and running on?
  • For getting you up on other servers, how long will that process take?

Questions for Development Team and Operations

Some questions you want to ask whoever is handling your development and maintenance operations:

  • Are you using an adequate version control system (like Git) to ensure changes to application code aren’t lost?
  • How is the environment (i.e., the many dependencies and system requirements that an app relies on to work) being monitored and backed up? If a server problem happens, ideally you want to have a firm idea of how that environment was created and how you can replicate it. (There is software available that automatically handles dependencies and keeps environments up to date, but not every company or team will want to pay for that.)
  • What monitoring of hardware metrics and app performance metrics is in place? Is the monitoring proactive or reactive? Ideally, monitoring and alerting will fit into disaster recovery plans. (We’ll talk more in a future article about monitoring.)
  • What deployment automation is there? Can a fresh server be built and the application get reinstalled by just pressing a button or running a script?

Back-ups

How are back-ups (of code and environment) being done? How are they being tested?

The only true way to know if your team’s back-up system is accurate is to test it; to completely reinstall the application from scratch on a new server. You don’t have to do that very often, of course.

All sounds a bit technical?

Our application audit service will do all the due diligence leg-work for you. We can audit your application and its infrastructure to give you all the information you need to put your own Disaster Recovery Plan in place.

Summary

Remember that, compared to the other aspects of application management we’ve talked about in previous software development guides, disaster recovery will fall much more onto the management’s shoulders. Hopefully this article has made you aware of many of the high-level issues to be aware of when investigating how your team is handling disaster recovery.

And if You Need Help…

If you ever need any help or advice, whether that be creating your own disaster recovery plan or help with your web programming, PHP upgrades or ongoing support, please don’t hesitate to get in touch.

Who’s “us”? We’re Siftware, a firm run by me, Darren Beale. I’m a long-time PHP consultant turned manager and my team includes other respected PHP developers. Over the years, we’ve worked with a diverse client list, overseeing their PHP development and providing ongoing support.

Our service offering is laser focused and we only work with owners or managers of existing PHP applications. If you would like to find out how we can help you please don’t hesitate to book a free consultation.