In an ideal e-commerce world, you would put up a website, automate all sales and services, check in once a while to reply to emails and count the money in your bank account at the end of the month. Your online business would run itself right from its launch-date and would keep doing so. Sadly, the online world is just as chaotic and unpredictable as real life is. There are events that can bring your website down: network jams, power outages, malicious viruses, hacker attacks and – worst case scenario – total server crashes.

Depending on what kind of attack you fall victim to, the damage you incur can include one, or all, of the following:

• Visitors cannot access your site.
• Clients/visitors cannot access their accounts.
• Clients/visitors have personal information, money or both stolen.
• You cannot access your website’s control panel, files or data.
• Everything (files, data and databases) is completely lost.

What is quite unsettling is the fact that you can never have a 100% guarantee your site will never crash. As a matter of fact, and in case you haven’t noticed, web hosting providers will never say that they can ensure your website will be running healthily with 100% uptime. They may get as close as possible to it (99.999%), but almost never the full 100%.

This should serve as a warning to you. You should get out of the “it will never happen to me” mentality and make sure you and your web hosting provider are taking all the necessary precautions and have a fool-proof disaster recovery or crash plan in place – just in case.

But, what should you and your web hosting provider do to create such a crash plan? Take a look:

1. Identify all the key components. Imagine a 100% loss where you’d have to bring your website back to life – from scratch. What would you need? Go through each step and note the files/data you would want. Once you reach the end, you will have a list of your key components. To be sure you haven’t missed anything, go through the drill a few more times – especially if you have recently added a new feature or service.
2. Remember that documentations, like process flow charts and schemas, are also important. Just because they aren’t an active part of your website, doesn’t mean they aren’t critical. You may need to refer to them in case you get stuck during the reconfiguration of your new site.
3. Figure out your bearable downtime. If your site is passive (hosts reference material, for example) you won’t do much damage to your business or your clients should your site be down for a full day. On the other hand, if you run a business that depends heavily on client-to-website connectivity or interaction (ecommerce, mail, lifesaving services, for example) you won’t be able to afford 10 minutes of downtime before you have your clients beating a path to your door. Your bearable down time, becomes the maximum amount of time you will have to bring your site up and running in case of a crash, and your whole recovery plan should fit in that timeframe.
4. Determine how often you want your backups taken. Again, with a relatively static site, you could get away with longer intervals between your backups. In an ecommerce or quick-access one, you would need to have them on a shorter, more often basis as your data changes very quickly.
5. Now, comes the part where you have to decide which recovery plan fits your website the best:
   1. If you have a long bearable downtime you can opt to have your site’s backups sent to you on a regular basis, you will have the luxury of restoring the site yourself. Your web hosting provider should be able to accommodate your request for regular backups – no matter how often you may request it (you may have to pay extra, though). Make sure you download and store your backups on at least three different storage devices or sites. Stick to a regular backup-schedule religiously.
   2. If your bearable downtime is too short for you to do a full backup restoration, work with your web hosting provider to get data or server replication. Should one site go down, your clients would be automatically re-directed to the backup site.
6. Test your backup by having regular restoration tests. You wouldn’t want to be saddled with a backup that doesn’t work – it happens more often than you’d think.
7. Once the plan has been set out and tested, document everything – from where the data is backed-up to what steps to follow for a successful restoration of the website. There is no point in having a crash plan if you’re the only person who knows about it and happen to be indisposed when disaster strikes.
8. In case you have the misfortune of having a disaster, and then a successful restoration, revise the steps and documentation and keep refining and/or tuning them to shorten recovery time.

A final piece of advice: Always make sure you are up to date on your backup policy and procedures. If you can’t do it, then you might need to consider looking into hiring online backup sites – of course that might come at a price.