If you are currently hosting your website in-house, or through a hosting provider/data center, you should know how your data is backed up, how long it will take to restore from barebones, and who to contact in the event of disaster.

If you are a website owner, manager, or webmaster, and the term disaster recovery is new to you, use this basic checklist to help you get started in building a disaster recovery strategy for your web business.

This article is a great resource to get started, and applies to smaller web businesses. Larger web businesses will consist of more advanced schemas which are outside the scope of this article.

Part 1 – we will focus on discovering what your current backup process is, and what it should be

Part 2 – we will make a list of the time needed to restore information should it be damaged, deleted, or lost

Part 3 – we will create a resource sheet and accountability for who is responsible for responding and executing in the time of a disaster

Part 4 – we will develop a schedule to review the backup process, and implement a monthly “mock” disaster scenario where we put the disaster recovery plan into action

Develop Your Plan in Advance
Defining a restoration strategy in advance of having a catastrophe prepares your team with an action plan for a successful restore. Understanding the intricacies of your backup strategy will help to uncover backup issues and minimize downtime when outages occur.

Communication
Open up a dialog with your server administrator, hosting provider, or software development firm to learn how your current backup schema is configured. Press them to answer your questions in a way that you can understand. This will help to pinpoint areas of concern and ultimately lead to their resolution.

Where to Start

1. What type of information should be backed up
First, define what should be backed up – make a list of your data sources, special programs, and other software applications. If your website data is on one server, make sure that all your data is being backed up, not just your files, but your databases, mail settings, server log files…

Example list:

  • Files; media (images, videos, PDF’s, etc..), programming code (PHP, HTML, etc…)
  • Databases
  • DNS records (MX, A, sub domains, etc…)
  • Server log analysis software
  • Server log files (generated by Apache)
  • Apache settings and configurations
  • Third party software systems (email marketing, ticketing systems, etc…)
  • Email settings (mail boxes (username/password), aliases, forwards, quotas, routing, SPF records, etc…)

2. Learn how your current backup process works
Understand the process for how you data is being backed up, what is included, what is not included, where are they stored, how much space is utilized, how far back your backups go, and how you can access them

  • Existing backup schema – what is currently included in your back up process? Make sure this list is clear and concise. Refer to the list you made in step one to ensure what you need is included in the backup processIf it turns out that your data isn’t being backed up, open a dialog with your host or server admin to start backing up your data immediately. It is usually a pretty straight forward process, and once configured, doesn’t require a lot of maintenance. The benefits far out weigh the negatives. 
  •  

  • What precisely is included with each backup – make a list of the actual data that is being backed up. For example, if your business has multiple domain names, and various email addresses, make sure that your DNS records are being backed up; specifically your MX, A, sub domains, SPF and any other applicable DNS records.Often hosts will backup folders within your domain, but not the settings, DNS records, and server log files. If you are currently using a control panel (like Plesk, HSphere, CPanel, etc…) to manage your domains, these systems usually have their own backup systems. Find out exactly what those systems backup.
  •  

  • Where are the backups stored – on site, off site or both, and on what machine. This is an important element that will help to determine risk factor in specific types of failures. For example, if your data is backed up on the same server, and your server’s hard drive controller shorts out destroying your active data and backed up data, you are in a bad position.
     
    Your data should be backed up on a separate server, preferably outside of your local network, in the case of intrusion, hardware failure, fire etc…Preferably, store your backups in a  separate data center in a different city or state. That way, should you datacenter experience a fire, flood, power outage, or go out of business, you have all your site data in a separate location.
  •  

  • How large is each backup – what is the size of each backed up type, e.g. how many GB are all your media files, database information. This will help to define a strategy for storing the data on separate servers or different data centers.Since database backups are typically smaller than media backups, it might make sense to store backups for the database files longer than media files.
  •  

  • What is the initial size of the backup? That is, most backups create a base backup, and then generate incremental backups of the files that change on a daily basis.You will need to know this if you decide to move the data to an offsite location. The initial base transfer will increase your bandwidth usage.
  •  

  • What is the incremental backup size? That is, how much data is changing each day and being incrementally backed up.Estimate your daily incremental backup to budget bandwidth increases and storage needs on separate servers, or in different data centers.
  •  

  • What is the rotation of your data – files should be backed up either hourly, daily, weekly, etc…, and should be rotated out for new files so you don’t utilize too much disk space.With the list made of what is being backed up, specify the rotation of each item, or if your backup includes everything, define when the backup is rotated out. Maybe your backup only goes back 1 day, or 1 week. Sometimes it takes some time to discover you lost some data, and if you only have a daily backup, you can’t restore a file that was lost last week.
  •  

  • How do you access your back up files, and what format are they in? Get access to where they are stored, and figure out if you need special applications to work with them.It depends on how your backup process is configured, some system require programs to extract data, sometimes you can only extract the entire backup. Get access to the files so you can figure out how to work with them.
  •  

3. Make a chart of your findings
Use Excel or Word to organize your results into a readable chart. This will be used for scheduled reviews and status updates.

I defined the Type of data being backed up, the Location of where the data is backed up to (in this example, the data is stored on a redundant, load balanced server, in addition to a separate data center), the Size (in gigabyte and megabyte increments), the Rotation (how many days back the data is stored for), and Includes (what exactly is included in the backup).

Once you have your chart ready, you are prepared for the next step! Please see the Website Backup Strategy Part 2 for the continuance of this process.  

Leave a Reply

You must be logged in to post a comment.