A new website — WordPress backup requirements

This is a continuation of a series of posts about reworking my website into one that is entirely WordPress based. The series starts here.

OK, so I’ve got a new web site, and it’s live. Job done, right? Well, no. Now is the time for one of the least glamorous, but ultimately most important, things in just about any computer system implementation: preparing for a disaster. Disasters come in many forms. There are fires, floods, earthquakes, and things like that. Those are thankfully infrequent, but still need to be considered. Then there are attacks from malicious people — or bots controlled by those people — that could corrupt your site so badly that you’d need to wipe it clean and restore a version from before the attack. Your hosting company could go out of business, or start providing service that’s so bad that you want to move elsewhere. There could be a hardware failure at your hosting company. Or, more likely, there could be a human error or software defect that corrupts your site. And, no matter how careful you are, there’s always the possibility that your yourself could screw up big-time.

For all those reasons, and probably a lot more that I haven’t thought of, you need to back up your data, and you need to back it up to several places, most of which are not on the servers that host your site.

Many people pick a backup solution and never test it. Some of those people find out only when they need to do a restore that there’s something wrong with their backups. You don’t want to be one of those people.

You need to do trial restores to gain confidence in your backups. I know that people don’t like to here that. I don’t like to have to say it, and I hate testing backups, but there it is. Now, as applied to WordPress sites, there is a conclusion that stems form the bold sentence above that may come as a surprise to you: a backup solution must be a migration solution.

Why is that? Because you don’t want to test a backup by restoring a live site. Tell me, how are you going to feel if in testing your backup by doing a restore to your main site if you end up wiping out a perfectly good WordPress instance, and you have no backup in which you have any confidence? Better hide the knives, pills, and guns before you try that. Therefore, any trial restoration has to be to a test site. That makes it a migration.

So, when you look for a backup solution, make sure it can do migration. Migration is sometimes presented as a minor feature of a tool that is advertised for backup. That’s the wrong way to look at it. You’re guaranteed to have to do migrations to test your backups. You may never do a restore to the site that you backed up. In fact, it is unlikely that you will have to. So, in looking for a backup tool, you might start up looking for migration solutions.

With a WordPress instance there are two things that need to be saved: the content files, and the database. If you have images in your content, they are stored outside the database (unless you are stupid enough to put them in-line in your posts, as I did for way too long many  years ago). Aside from that, your pages and posts are stored in the database. You may also want to backup your plugins and themes, especially if you’ve done a lot of customization and aren’t sure where that is stored.

So, the first solution I’m going to propose (and the only one I’m going to talk about in this post) is the conceptually simplest one, but requires the most user involvement. Use ftp to back up your files and directory, and use a database migration tool to back up your data base.

It turns out that I’ve already told you about a database migration tool in this series of posts. I used WP Migrate DB Pro. I used that to migrate the test site at kasson.name to kasson.com/wp1. It worked very well. There are four  modes to the plugin. It can push a datbase to a WordPress site with the plugin installed, it can pull a database from a  site with  the plugin installed, or it can download a database to your computer or upload one from your compute. I used the two peer-to-peer modes for the migration. For backup and backup testing, the database download (backup) and database upload (restore) modes are the ones to use. Unlike many backup pplugins, there is no timed operation for WP Migrate DB Pro; if you go that route, you’ll have to manually invoke it whenever you want to do a backup.

I’ve done a couple of successful migrations/test restores with WP Migrate DB Pro, with WordPress databases of around 10 MB. I’ve had problems with a database of around 500MB. More work is necessary for me to gain confidence in the product as a database backup solution.