There are many ways one might approach the topic of web site backup best practices. I wanted to provide an article on this topic, as it’s something relevant to my current and potential clients, and also generally useful information for most business owners. So, let’s look at some common approaches. For fun, I’ll call these “levels”:
Level 0: Nothing
Really, the default position many companies are in when it comes to this is that they’re doing nothing at all, which is not good. The only justification for this is an assumption that someone along the line — maybe the host, maybe the developer — has a backup of your site. But, that may or may not be the case. Of all the “levels” here, this is definitely the worst, and a recipe for disaster.
Level 1: Relying on the Web Host
As a web developer, I’ve been able to see the inner workings of many, many web hosting companies, and can tell you that their approach toward backups differs wildly. Some hosts claim that automated backups are incuded, but it turn out that it’s up to you to set them up. Some offer auto-backups, but only do it every so often. Some backup files and not databases. Some offer utilities for restoring individual files, databases, or whole installs as of certain dates.
Basically, it’s not always clear what’s being backed up, what the schedule is, what the restoration options are, or how long files are kept. So, that’s something that you should look into, if this is your method.
Level 2: Relying on a Web Host’s Paid Service
Other hosts offer backups as a premium, and usually offer more control over the varuious areas mentioned above (scheduling, etc.). If you pursue this type of backup, one thing you may ask is whether the backups are stored on the same server or not. The preferable answer would be no, but this varies from host to host.
As far as I’m concerned, this is sort of the minimum level where most business web sites should be. True, the above “level” might save you, as well, but this level seems safer to me. Still, there are better approaches.
Level 3: Pulling Periodic Backups Yourself
Here, we’re getting to people who really like to be in charge of things. Hopefully, if you’re someone who does this (and, I do this all the time), you’re aware that, not only do the files need to be backed up, but also the database(s). If you’re a WordPress or Joomla! user, my personal favorite tool to help facilitate this is Akeeba Backup. (I’m not affiliated with them; they’re simply my preferred software for this.)
Akeeba allows you to, with a single click, backup all of your site’s files and database(s). (It’ll also help you with the next few levels!) You still have to login and make that click, though, so let’s level up again, shall we?
Level 4: Cron Job Backups
For many, an even better approach is to setup a cron job on your web server to automatically pull backups on a schedule (e.g., daily, weekly, monthly) as best fits your site’s needs. If your site rarely changes, then a monthly approach might be best, for example.
Personally, I tend to use crons, but “supplement” with one-off backups prior to, or just after major changes, just to be safe.
Level 5: Off-Server Storage
The next rather important aspect is the storage of your backups. Commonly, people backup their sites, but then store the files on the web site’s file structure somewhere. This works well for routine failure scenarios like corrupted CMS files and whatnot. But, what would happen if the hard drive that your site resides on fails completely? Well… your backups would be unretrievable.
So, as a best-practice measure, I fell it’s best to setup web backups to be stored in the cloud—Amazon, Dropbox, etc. Combined with a cron job, this provides probably the highest practical level of backup readiness, although one could also take things to the extreme, as in the next level.
Level 6: Extreme
In addition to all of the above, I’ve seen a few clients who not only store files in the cloud, sometimes in multiple places, but also one’s who’ve downloaded the entirety of their sites, periodically, onto external hard drives, which would then be stored somewhere not even connected to anything (powered off, presumably preserving the site in case of, say, some massive solar flare that wipes out the server as well as any cloud-based backups).
I guess that would have to be one heck of an event, which would probably mean a lot of larger problems for mankind. But, aside from printing out every page of a web site for hard-copy backup as well, this may not be a completely terrible idea for those concerned.
Level 7: Testing
The final item I’d mention is that, all of these backups are fine and dandy — and, having restored many, many sites (or moved servers, which is a similar process), I can say that the backups generally do work. But, still, in the interest of thoroughness, it would be prudent to periodically test backups to ensure that they do, in fact restore successfully (e.g., and have not been corrupted during the backup process, which is rare, but can happen).
My final point would simply be: Are you aware of the process being employed with respect to your web site? If not, it’s a good thign to have documented. (I’ve had clients that have requeted this documentation, as a matter of fact, usually for various insurance purposes.)
In many cases, whatever “level” is employed by your company, it’s likely a good item to note within a larger corporate backup plan, which most companies also (hopefully) have in place (but which is not covered in the scope of this discussion).
- get the web / database backup on a regular cron
- optionally, pull a new backup manually before and after any major work
- store all backup files off-server
- periodically test to ensure functionality