What’s your web application back-up plan?

You’ve invested money and time into your web application development project and now have it running live on your server – congratulations.  Your hosting provider tells you that they have weekly back-ups in place.  You can now sleep at night, right?  Well, not necessarily.

It’s critical to understand what is being backed-up, how, and how often.  Your back-up strategy should be tied to being able to recover your application if disaster strikes.

Web Application Components

To develop an approach to back-ups, you will first need to understand the various components of your application and how they relate to backing-up data.

Source code
Your source code is your intellectual property and the output of your development process.  You will want to keep a back-up of your source code in a safe place – ideally in a version control repository such as GIT or SVN that resides on your company network and in some “off-site” back-up location such as a cloud storage service, or on an external drive that is not physically in your office (in the event of a fire or other catastrophe).

Your source code will change as you make changes to your application (new releases, bug fixes, etc.), so it’s important to update your back-ups if your code is modified, but if not, then a one-time snapshot of the most recent code is usually sufficient.

In a worst-case scenario, you can use your source code to re-deploy your application to your production system.  This is not ideal, however, since there is often aspects of your application that are changing and growing as time goes on and are not part of your source code (such as data in a database, files on the file system, etc.).  Your web application usually consists of much more than just the code needed to make it run.

“Running Code”

Your “Running code” (sometimes referred to as binaries, run-time code, and other names) is the code that has been packaged up and/or compiled based on your source code and then deployed to your server.  This is essentially the code that is currently running in your production environment.  Strictly speaking, this code is static, and would not change from day-to-day unless you were to update the source code (fix bugs, add new functionality, etc.) and then re-deploy the updated code to the server in which case you would want to take a new backup of the latest code.

Database

Your database is likely the most ‘dynamic’ component of your application.  Anytime that end-users are adding data or updating data (placing orders, updating profiles, posting media, performing tasks, etc.) it is likely that changes are happening in your database as a result.  Data is constantly being written, edited, and deleted.  Therefore, your database is usually the component that needs to be backed-up on the most frequent basis since it’s the part that changes most frequently.

File System

Depending on the nature of your application, you may also have files that get generated and/or uploaded as part of your application and are then stored on your server’s file system.  Some examples include photos, document files, text files, reports, PDFs, etc.  that are created by your end users or the administrators of your application.  Like the dynamic nature of database data, these files will also need to be backed-up frequently because they likely either change frequently or new ones are created on a frequent basis.

Recovery Plan

You will want to come up with a recovery plan if something bad should happen to your server.  This could include hardware failure, server software failure, or a disaster such as a fire or flood at your hosting facility.  You should discuss and understand your back-up and recovery options with your hosting provider to make sure that you are covered in these situations.

For example, creating a daily back-up of your application, database, and any associated files and storing that back-up on your server itself, is probably not a good plan.  This is because if something were to happen to your server, then not only would your live application be down, but you would lose all of your back-ups on that server as well.

A much better plan would be to create frequent, automatic “image” back-ups (essentially a carbon copy of the entire server with all the software components) and store those images somewhere in the cloud at your hosting provider.  This would enable you to get back up and running very quickly should something happen to your primary server.  The frequency of your back-up would then dictate how much data would have been lost.  For example, if you take an image back-up once per day, then you can restore to that last point in time and in theory you would lose a day’s worth of data or less.

You should also take periodic back-ups of your running code, database, and file system and store them “off-site”.  Essentially this means downloading them from your server and storing them at your office and/or in some other cloud storage service.  This would guard against something happening at your hosting provider which would prevent you from accessing the image back-ups (insolvency, a disaster at their facilities, etc.).

Summary

  • Understand the difference between source code and the code running on your server.
  • Know the various components that comprise your application and the frequency that data changes in each.
  • Ask your hosting provider about the options available for back-up and develop a back-up strategy based on your risk tolerance.
  • Make sure to have ‘off server’ and even ‘off site’ back-ups of your system for recovery in worse case scenarios.