WordPress Security Series: Backups

Backups are important, right? We all know that. Even so, every time we hit a problem with a website, a server, or a device, we think, I probably need to do regular backups.

If you are still wondering, then yes, you do need to make regular backups. This is vitally important to your web site and something you shouldn't assume your host is doing. If you are not doing regular backups: stop now, shut everything else down, read this article and then setup your backups. It is that important. 

Forward thinking infrastructure partners like Pantheon provide an option to  make backups from the control panel. If your infrastrcuture partner does not provide this service, or you manage your own platform, this article is for you.

Note: If you are a Pantheon customer, skip this entire article. Instead, just spend two minutes checking your dashboard to make sure you are backing up your website, and another five minutes restoring one to development. It worked? Of course it did. Now you're done. Go play some Minecraft. Everybody else, let's get busy.

It sounds so easy, right? Just make a backup. So few sites actually do this, or worse yet, do it correctly. It is so easy that it is really low hanging fruit. As of this writing, there are 600+ plugins with the word backup in it. One of those will surely do the job for you. 

What to Backup

You do not need to backup everything. Most of the time, when developers create a backup system, we filter out a lot of files that are either fluff—ones that can easily be recreated—or can be downloaded elsewhere. The important files you need to download on a regular basis are all contained in your wp-content directory. The one major exception to this is your wp-config.php file. Your wp-config file is located in the root directory of your blog. It is vital to your blog and needs to be backed up.

Within your wp-content, there are still things you don’t need. If you see a directory named “cache”, “w3tc”, or anything that looks like a cache directory, it is safe to exclude these from your backup.

You can, however, back all of your files up (WordPress core, plugins, themes, caches, etc.). A backup containing all of your files will be considerably larger than a selective backup. However, a full backup is much easier to restore, should you need to.

What Not to Backup

Any file ending in:

• .tar
• .tar.gz
• .bz
• .zip
• .tmp

This isn’t an exhaustive list but it’s a good start. These are either archive files or temp files. Neither are part of most WordPress sites. You may find that you have many “tar balls” sprinkled throughout your directory structure. My advice is to consult with a developer before deleting these files. If you don’t have a developer, or just can’t wait, then copy them somewhere safe and then delete them one at a time. After deleting each file, wait. Use your site for a few days. See if anything has changed. If nothing has broken, move on to the next file.

Database Backup

For most blogs, your database is going to change more than anything else on your site. Keeping it backed up will go a long way to keeping your site safe. If all you do is back up your database, should something happen you can still quickly get back up and limping along. It’s not optimal but it's better than nothing.

One quick and easy way to keep your database backed up is to use a tool like wp-db-backup. This plugin requires no technical knowledge whatsoever to install and configure. Once you have it installed and activated, give it your email address. Then, on the schedule you have set, it will email you a dump of your site’s database. You now have off-site backups of the most precious thing about your site, the database.

Here is a quick tip. Do you use gmail? Have wp-db-backup email the backups to your gmail account. Next, set a rule in gmail to automatically delete them as they're delivered. Gmail will not empty the trash for 30 days. If you do this every night, you will have a rolling 30-day backup of your database without having to lift a finger.

Off-Site

Do not just backup your site to the server you are running your site on. If the hard drive crashes—and they do—you lose the whole thing. Instead of a website, or a backup you can restore from, you have a smoking crater where your site used to be. Off-site is the only acceptable option.

There are plugins that will back your site and database up for you. If you subscribe to the service, they will also move the backups off to their server for safe keeping. You may want to research some of these services. You can however, with a little creativity and an hour or so of a developer’s time, create a solution that works for you.

That is exactly what I have done. It took me less than an hour to write a script that runs every night on my server. This script backs up only the files I absolutely need. I can download WordPress Core anytime I want. However, a dump of my database, my wp-config file, and my wp-content directory are all irreplaceable.

These nightly backups are automatically downloaded to my personal server for safe keeping. They are rotated out after thirty days. They are small enough so that I have room for ten times that number, but thirty days seems like a good compromise.

Test Your Backups!

Once a quarter, every six months, however often you think is necessary, run through your emergency restore drill.

DO NOT DO THIS ON YOUR PRODUCTION SERVER.

Use your development server. If you don’t have one, rent an Amazon EC2 Micro instance for a day. Whatever you need to do, test your procedure.

If you do not have a procedure for restoring your backup, get one. If you are using a backup plugin, chances are good that they have a restore option. Test it. Write down exactly what you have to do to restore your site from a backup. Test this procedure on a regular basis.

If you have hired a developer to roll your own backup solution, make sure that they provide you with explicit instructions. Hand them to a different developer and ask them to follow them to restore your site on a backup server. If they can’t follow them, get the instructions clarified until the second developer can follow them.

Remember this always:

“You do not have a valid website backup strategy until you have a tested recovery plan.”