But CloudFlare does other things than just deliver copies of your network. It also provides protection against various forms of attacks, and it provides a fast nameserver service for your website – a nameserver is what allows visitors to find your site.

Think of a Content Delivery Network (or CDN) as basically a chain of outposts for your website with location all around the world, and your name on the door.

But my website works fine – isn’t that enough?
No, it’s not really nowadays. The days of hosting a static website on a server in a corner of a data center is over. With the current speed of mobile/cell phones, and internet connections people expect a rapid website. Now, if you’re a local shop owner in – say – Santa Barbara – and your provider is just down the road, it might very well be enough, and nothing else is needed. At least until someone takes a run at your website and either tries to crash it, or even worse – hack it. You see a CDN does more than just provide faster service. It also protects against a DDOS attack, and can provide Firewall rules. Even if you have your own Firewall, they can protect your site from ever being reached. You can actually hide your website completely behind a CDN so nobody can see where it is.

CloudFlare also provides a fast, free DNS, which is always a plus.

It also means you can save $$$ on your hosting plan, since you can have a small server behind the CDN as they provide the horsepower for serving the data to the world.

Benefits:

• Firewall
• DNS service
• DDOS protection
• Content Serviing

The best part of CloudFlare is that the basic Tier is free. As in zero dollars. There is no sensible argument for NOT using them, even IF you’re a local shop, and once you go from local to regional, national or worldwide it’s an absolute must.

You need not just multiple backups, you also need to actually TEST how to restore everything if disaster strikes. Have you tried this? You should. We’ve seen (and experienced) trying to restore a backup only to find it was maddeningly convoluted.

Disasters happen. They can happen at several levels. At the simplest level, someone deletes a post by accident. This is easy enough to recover from the backup. Or is it? The problem is the backup has the entire site, and what if there have been other changes since. Now it’s suddenly not that simple any longer, because if you restore the latest backup you might lose changes since then, or even worse – customer orders.

Let’s take it a step further – your site gets deleted. By accident or by malice, this can happen. What then? How do you get it up and running again fast? If you’re running a WordPress site, you need to set up WordPress again, install the program you took the backups with, and then… Wait, you didn’t save the backups on the webserver did you? If not you can just restore it from your offsite backup (here is where the offsite comes into play), but if the backup was just a copy on the server itself, your site or shop is now basically burned to the ground and gone.

What happens if the datacenter where it’s located burns? Rare, yes, but it’s happened before. So your backup was offsite, but still in the same datacenter? Then your data was burned to the ground as well.

For a multitude of reasons you should not trust a single backup location, or backup program – what happens if the files are defective due to a bug in the backup program, and all your backups are basically unreadable? You need backups at multiple levels, and locations.

It might sound overly complicated, and you might think we’re paranoid. Chances are you’ll be fine, and will never need it. But think of it like insurance. You’ll be really happen you have it, once disaster strikes.

So, how do we do backups in-house?

We do it at 3 levels basically – from the outside we take snapshots of the entire server within our hosting system. We can use those to near-instantly restore a complete site – even elsewhere if needed.

At the second level we do it in the server itself, where we take backups stored both on the server (for a quick restore), and copies stored remotely.

Finally we do it within WordPress (with for example UpdraftPlus) – this takes a copy of your website to 1+ offsite locations, and can do it frequently. This also allows us to do offsite development of a site, where we copy the site to the development server – do the work, and copy it back.

So yes, we use both several belts, and multiple suspenders. Once set up, it runs by itself (we still test it periodically to make sure the backups actually work), and our sites are protected against all but complete armageddon for what amounts to peanuts compared to the cost of redeveloping a site.

It has actually saved our butts more than once (but that’s an even longer story).