How to Backup your WordPress Website

During our travels (mostly from the office to the pub) we often get asked “How do you backup your WordPress websites?”.

Closely followed by “My backups sometimes just don’t work.  Why? Why? Whyyyyyyyyyyyyyyyyy?”

Ok – perhaps a little bit overdramatized there but you get the idea.

Backups? I don’t need any lousy backups

In general, most of the business owners I have talked to who have a WordPress site don’t back it up.

There is one exception and that’s those who have had their site hacked or corrupted.

They now back up their site and therein lies the lesson.

You need to be backing up your website from the day go.

Think of it as an insurance policy against your business.  Especially if you actually trade through your website.

Here’s how to backup your WordPress website.  Now there’s no excuse!

Which plugin should I use?

There are many many backup plugins so how do you choose the right one?

It can be a difficult choice but here are some pointers:

• On WordPress.org, look at the reviews, the star ratings, how many downloads and the last time it was updated
  Don’t use a plugin that’s not been updated in over a year
• The plugin needs to backup both your database and files
  Some only backup the database and some will only backup your theme folder.  Read the FAQs carefully.
• Look at the backup frequency
  weekly, daily etc.  Does that match your requirements?
• Where can it store backups?
  Amazon S3, Dropbox, FTP?
• Ask other WordPress site owners which plugin they use and how it works for them

We’ll tell you our backup plugin of choice and why later in the post.  Can’t wait? ‘aright click here but you’re missing out on the good stuff!

How do (most) backup plugins work?

It’s important to understand how the backup process works in WordPress as this can answer the question of why some backups don’t run when they are expected to.

WordPress has an internal scheduling system called WP Cron and backup plugins hook into that system allowing them to run at intervals, daily, weekly etc.

Your scheduled posts system also uses WP Cron.

The name Cron comes from the ye olde UNIX server command to schedule a task – more on that later.  You’ll see why.

The WP Cron scheduling system is bizarre.

Many people would rightly assume that a scheduled job would run, well, on schedule.

So if you were to run your backup every Sunday at 3 am it should do just that, right?  Wrong.  Well, maybe wrongish.

There is a caveat to the WP Cron service.  In order to streamline performance, the developers of WordPress decided to link the WP Cron system into the WordPress site activity.

The theory goes, that if nobody is looking at your site, then there’s no real need to run WP Cron.

Now, this can cause issues of course for websites with a low number of visitors.  You may find that your scheduled posts don’t publish and that your backups don’t run.

Using an alternative WP Cron

WordPress has an alternative method of scheduling tasks, however, even the WordPress developers mention that this method is “unreliable at best”.

You can give it a go and see if it works for you.

Add the following lines in your wp-confg.php file.

[gist id=8143091 file=code-snippet-1.php]

The big drawback in using this method is that it’s still dependant on visitors viewing pages and it may screw up your SEO as it appends some rubbish to the end of your URL’s similar to:
?doing_wpcron =1345020206.5328660011291503906250

It looks nasty in Google Analytics.

The Loopback Issue and shared hosting

Adding fuel to the fire is what’s known as the “loopback issue”.

WP Cron uses something called HTTP loop backing to perform its tasks.  Essentially this just means that the website is calling jobs on itself.

There are a lot of shared hosting plans that disable HTTP loopback and for good reason.

If you have a server calling a URL within a URL there’s the chance of creating an infinite loop where the server keeps calling itself and running up more and more machine resources until it screams and falls over dead.

If you’re on a shared hosting plan and loopback is disabled, essentially this means that your scheduled posts, backups and anything else that uses WP Cron will never work!

Getting your backups running

All is not lost however, you can get your backups running when you want them to and even on shared hosting.

At Zero Point Development we use the backup plugin XCloner and we love it!

How do we do it?

We use a server Cron job to run an XCloner backup script that uploads the backup files to Amazon S3.

It may sound like a complicated process but it isn’t really.  Let me break it down for you.

Remember we talked earlier about ye olde UNIX Cron jobs?  We’ll we’re going to be using one and I bet you never even knew you had them.

First, you need to set up XCloner.  I won’t go through all the options as it’s fairly straight forward.  We pretty much leave all the defaults on anyway.

I’ll assume you have an Amazon S3 account, otherwise, you can use an FTP site to store your backups on.

Don’t go backing up your files to the same server.  They need to go somewhere else.

Open the Crontab in the XCloner plugin settings.

Add a file name into the Configuration Name field.  In the example above we’ve used my-backup.

This will save your XCloner backup options in a file called my-backup.php and we’ll use this to in the Cron job later to perform our backup.

The next thing you’ll need to do is define where your backups are going.

We use Amazon S3 but as you can see from the image above, you can also provide FTP details or even get the backup to email you with the files.

Another useful option is the ability to delete old backups after a specified number of days.  If storage costs are an issue this could help you keep space to a minimum.

You can also exclude any directories such as wp-admin and wp-includes which you can always get back from installing WordPress again.

That’s all for the XCloner settings.  Now we need to create a server Cron job.

We do need some information from XCloner though so navigate to the XCloner > Administration > Cron area

You’ll see that XCloner has worked out the complete path that the server Cron job needs.

Copy everything in this field to the clipboard.  Note: it will be different on your website so don’t just copy what’s in the image above.

cPanel and scheduled tasks

The last thing we need to do is to set up the server Cron job and for that, we’ll need to login to our hosting control panel.

We use cPanel but you’ll find an option for Scheduled Tasks in most control panels.  If not, just drop your hosting company an email.

The scheduled tasks (Cron) options may differ slightly on your cPanel but the outcome is the same.

Paste the content of the XCloner Cron settings you copied earlier into the command line field.

Set the schedule.  Here we’re backing up every day at 4 am.

If there is an option to test your command, use it.  This will run the command and give you a report on its success or failure.

You may have to wait a few minutes before getting a response back.  You should, of course, check your backup destination to see if the files have been properly transferred there.

And that’s how we back up our own and client sites.  Simples!

Should I use a paid service?

We find XCloner is very flexible for what we want to do, however, there are instances when your website is so critical to your business, such as an eCommerce site, that you’ll want an even higher backup frequency.

We would suggest you use VaultPress for this.

This is a premium service so you’ll have to pay a monthly subscription.  There are two choices 1) backup daily and 2) real-time backup.  Real-time backup is a must for high traffic and eCommerce websites.

Was this post useful to you?  Let us know.