Your website is most likely up 99.9% of the time, and you don’t have too many conversations with your hosting support team. That is, if your site is online and operating as it should. Where you start spending a lot of time writing emails and making phone calls is when your web site goes down due to a server outage, hardware failure, data center contingency, or myriad of other reasons.

Ecommerce Website Backup Strategy

Whether your working on a single website, or a cluster of complex software applications, take the upfront time to standardize the method to control the source code, and task schedule. You will be grateful for this when your lead developer quits, or you hire some new team members.

A version control system (VCS) is basically a running log of all the source code changes within your website. It allows a developer or designer to quickly analyze source code changes and enables them to revert, modify, or delete changes with simplicity.

A VCS will play a critical role in the development of your project when you have various team members, or iterations to your source code. For example, let’s say you have two developers; a lead developer and a entry-level developer. The entry level developer can make changes to the source code, and the lead developer can quickly verify these changes to ensure they are coded properly. The software creates a full account of all changes to all files, and identifies where the changes were made, by who, and when. The lead developer can then accept the changes and push them to the live source code base, or reject the changes and push them back to the entry-level developer to fix.

The real benefit in using this system is it does not require a high level server administrator or developer to manage or use. Anyone on your team can access the source code changes, verify schedule and tasks, and gain some insight into the project from a basic web browser. This is a powerful tool for a project manager or webmaster.

Version Control Software
There are many parts to a version control system. It starts with the actual technology used for managing the source code. A few of the different software applications that are responsible for managing changes are; CVS, Subversion, Git, Mercurial, Bazaar, the list goes on…See a great break down of the different systems at http://www.smashingmagazine.com/2008/09/18/the-top-7-open-source-version-control-systems/

Interface Tools
A VCS is the under-the-hood system installed on your server which is responsible for logging all changes to the source code. The next part of the equation is the interface you used to communicate with the VCS. For example, when you upload files to your server, you probably use some sort of FTP client to transfer the files. Much like an FTP client, the VCS interface tool allows you to easily commit, revert, and access the source code base. These tools make accessing the VCS extremely simple for your designers, project managers, developers, etc…

Project/Task Management Software
The project and task management software is the system that makes the changes easily accessible and available for tracking, documentation, and communication. For instance, a project manager can access the entire project from his web browser to verify tasks, bugs, and time logs of his team members. With this information, decisions can be made to prioritize and escalate tasks. This system is the engine behind the management of the project.

Key benefits of using these systems:

• One centralized location to manage all of your projects with ease
• Your projects will be fully documented with the changes and why those changes were made and by who
• Backups of all changes are stored within the VCS, and in the case of errant code, can quickly be restored
• Bug tracking and resolution made easy and efficient
• Task scheduling and resource allocation is tied in directly with work accomplished (source code changes)
• Time tracking per task, project, etc..

So hopefully you now understand the importance of these systems and are ready to take the next step. I am going to outline the systems I use, and why. There are dozens of different configurations, however, I have found that for small teams, with limited Linux experience benefit from the configuration below.

Choose Your VCS
First off, I used Subversion (about 5 years ago). At the time, our code changes were only rolled out to the development server every 12 hours. Eventually, we were able to roll out the changes every 5 minutes, and then were finally able to roll out changes with a post-commit hook (which means someone needed to trigger the system to activate the changes). This was not efficient for our designers who were working on browser compatibility and advanced CSS/HTML code. It killed their productivity because every little tweak they made required 30-60 seconds of extra time to implement. Added up throughout the day, and we lost a lot of time.

Subversion is much slower to roll out changes, as it stores all the projects in a centralize repository. So, whenever you query the system it needs to run through the entire source code base of all your projects to implement the change. If you have a lot of projects/source code, this could cause some major delays.

Anyway, we moved on to a few other systems that were better than Subversion but too hard to use from a Windows system. That is, the interface tools were quirky and difficult to work with.

We finally tested and implemented the Mercurial VCS, which is fast, powerful, and has some great interface tools. It is also very easy to use, and scales well for larger projects.

Benefits of Mercurial VCS:

• Ease of use
• Commits/changes are made instantly (good for designers!)
• The interface tools are well adapted for Windows and non-technical people
• Easy to setup and minimal amount of upkeep/maintenance
• Decentralized system, which stores each project within its own repository
• Advanced tools for branching, tagging and merging source code (for more technical teams)

Choose Your Interface Tool
So if you are using Mercurial, and your on Windows, I recommend using TortoiseHg which is stable and easy to use. It is a shell extension which shows up in your Explorer context menu:

The one downside to Mercurial is that there are no plug-ins for Dreamweaver, which means your designers (if they use Dreamweaver) will have to manually commit files to the repository-they cannot do so through Dreamweaver.

Choose Your Project/Task Management Software
I have used various project management systems; two of my favorites are Trac and Redmine. I first started with Trac, which has some powerful tools, but is limited when it comes to managing multiple projects and source code repositories. That is, they don’t have stable tools to quickly access all your projects, users, and project materials. My server administrator recommended Redmine, which has nearly all the tools of Trac, and then some.

Benefits of Redmine:

• Quick and easy management of multiple projects
• Comprehensive user management/restriction system
• Feature rich (per project wiki’s, defect tracking, time logs, news, document/file repository, threaded bulletin board for team communication)
• Per project and overall activity log
• Customizable fields for defect tracking (severity, priority, status, etc…)
• Excellent search feature
• Excellent usability
• Calendar and Gannt view features

Calendar feature

Gannt feature

Redmine is a very stable and versatile system that is easy to use and extremely flexible. Try out their demo at http://demo.redmine.org/

This system enables the project manager to see the under-the-hood changes to the project, as they happen. It creates a repository of all communications, and assignment of tasks, as well as establishing a library of notes on the project, which can be saved indefinitely.

Start assigning workload to your team through Redmine, and see how easy it use to use and manage your projects.

If you are a website owner, manager, or webmaster, take the time to review the different hosts and server scenarios available to you. There are a plethora of different hosting companies out there-use the attached checklist to make sure you don’t get swindled!

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.

Download the spreadsheet here: Web-Hosting-Checklist

Define Your Hosting Needs
The first step in the hunt for the perfect host is to be clear in what you actually need. For all intensive purposes, you are probably going to need either a dedicated or shared server. Choosing a server type is beyond the scope of this article, but for a frame of reference:

Dedicated Server
A dedicated server is usually managed and maintained by your hosting provider. That is, in many cases, your host will provide support for the server hardware, and sometimes, the software. However, you will have sole control over the server, as it is not used for any other purposes other than your own. You can usually install whatever software is needed, and configure the server based upon your specific requirements. As opposed to a shared server, where your website will be competing for the same processing power as hundreds or even thousands of other websites. This option is going to be more costly, although the benefits include control and scalability.

Shared Hosting
Shared hosting makes up the majority of hosting providers out there-it is the bread and butter of the hosting world. Most Software as a Service applications (Yahoo Stores, Volusion, MonsterCart, etc…) are shared hosting providers. And many of the low cost hosting plans are based off of shared servers. You are sharing a server with various other websites, and are limited to what you can do, which why it is more economical. Although, many larger companies that are utilizing a shared server approach have a sophisticated architecture with multiple redundant servers. This means that if one server should fail, another will pick up where the failed one left off.

There are also collocated servers where you have full responsibility of the hardware and software, and are simply renting rack space, electricity and bandwidth.

Beyond the type of server you’re going to need, define what the actual requirements will be on a software, hardware, and support basis. Perform some research to find the answers to the items in the checklist before you start contacting hosting providers. This will ensure you have a clear set of requirements available for an accurate quote from each provider.

Find Hosting Providers to Contact
Other than your typical Google search; I would recommend the following hosting specific forums:

http://www.webhostingtalk.com/

http://www.sitepoint.com/forums/forumdisplay.php?f=96

It is going to be challenging to find a quality host at a low price. Quality meaning they have an SLA for: response time on tickets, outages, and hardware replacement. They should also guarantee an uptime of at least 99.999%, which means your server can be down for about 5 minutes a year (this does not usually account for scheduled maintenance).

Another great resource to learn of higher end hosting providers is to use the Gartner Magic Quadrant

Take care to add your own requirement specific questions to the list (Web-Hosting-Checklist), and compare the answers to find the best provider for your needs.

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.