How often you back up your WordPress website should match how much work you can afford to lose. A brochure site that changes once a month is fine on weekly backups. An active blog needs daily. A WooCommerce store taking orders needs hourly at minimum. And wherever those backups go, they cannot sit on the same server as your website.
Most business owners know backups matter. Most also assume they are probably covered, because the host mentioned backups at some point, or a plugin was installed years ago by whoever built the website. That assumption holds right up until the morning you need to use one.
Why backups are non-negotiable for any WordPress site
A backup is the difference between a bad morning and a rebuild. Without one there is no version of your website to go back to, so the only option left is building it again from whatever survives in your inbox, your head and the Wayback Machine.
The things that take websites down are ordinary rather than exotic:
- A plugin update that conflicts with your theme and leaves a white screen
- A WordPress core or PHP update that an older plugin was never written for
- A compromised login, or a vulnerability in a plugin nobody had updated
- Server or database failure at the hosting company
- Someone deleting the wrong page, or pasting over the wrong template
Human error is the most common one on that list and the least talked about. Nobody writes a blog post about the afternoon they deleted the services page.
Security problems get more attention, and they are worth taking seriously. A WordPress security audit will tell you where your website is exposed. But a clean audit does not remove the need for a backup, because the failed update and the deleted page are still waiting for you. The same goes for keeping your website updated: updates are how you avoid being hacked, and they are also the single most common reason a website breaks. You want both the updates and the way back.
How often should you back up your WordPress site?
Back up as often as you create work you would not want to redo. That is the whole rule. The practical version is to look at how often your website actually changes, then match the backup frequency to it.
| Type of website | How often it changes | Backup frequency | What a failure costs you |
|---|---|---|---|
| Brochure site, a few static pages | Monthly or less | Weekly | A page edit or two |
| Blog or news site | Weekly | Daily | A post, maybe two |
| Membership site or busy blog | Daily | Daily, kept longer | A day of comments and signups |
| WooCommerce store | Continuously | Hourly, or real time | Orders, and the customers attached to them |
The store row is the one that catches people out. Daily backups on a store mean a failure at 4pm can cost you every order placed since midnight. Those orders are customers waiting on something they have already paid for, and restoring yesterday’s database will not tell you who they were.
If your website takes payments, treat backup frequency as a business decision rather than a technical one. Work out what a lost morning of orders is worth to you, then pick the frequency that matches.
The golden rule: where to store your backups
The 3-2-1 rule has been the standard answer in IT for decades and it survives because it is simple to hold in your head: three copies of your data, on two different types of storage, with one of them somewhere else entirely.
For a WordPress website that translates to:
- The live website, which is copy one
- A backup on or near the server, which is copy two and the one you will reach for most
- A backup somewhere unrelated to your hosting, which is copy three and the one that saves you
The third copy is the point of the whole exercise, and it is the one most often missing.
A backup stored on the same server as your website is not a backup. It is a second copy of a file on a disk that can fail. If the server dies, the backup dies with it. If the website is compromised, an attacker with write access to your files has write access to the backups sitting beside them, and ransomware aimed at web servers goes looking for exactly that.
Off-site means a different system, not a different folder on the same machine. On the websites we host, the nightly backup is written to Amazon S3 rather than kept on the web server, so losing the server does not lose the history.
Why “my host backs it up” isn’t a real strategy
Your host probably does back something up. The question is whether that backup is one you could actually use at 9am on a Monday, and often enough the answer is no.
The gaps turn up in the same few places:
- Frequency. Weekly backups on a website that changes daily.
- Retention. Seven days is common, and problems have a habit of surfacing on day ten. A compromise can sit quietly for a fortnight before anyone notices, by which point every backup you hold is compromised too.
- Location. Backups kept on the same infrastructure as the website, which fails the off-site test.
- Access. Some hosts will restore for you but will not hand you the file, and some charge to give back the backup they took on your behalf.
- It was never switched on. Backups are a paid add-on on plenty of plans, ticked at signup or not.
None of this makes hosts dishonest. A backup thrown in at no cost on a cheap plan is doing a cheap job, which is fair enough. The mistake is treating it as your strategy rather than one layer of it.
It is worth ten minutes finding out what yours actually does. Log in to your hosting control panel and answer four questions: how often does it run, how long is it kept, where is it stored, and can you download one right now without asking anyone.
Testing your backups: the step everyone skips
An untested backup is a guess. Backups fail quietly, in ways that stay invisible until the day you need them: a database export that timed out halfway through, an uploads folder excluded from the file list, a scheduled job that stopped running eight months ago and never mentioned it.
Testing means restoring. Not opening the file to confirm it exists, but putting it onto a staging environment and clicking around. Does the homepage render, do the forms submit, are the products and orders there, does the admin log in. A restore also puts the website into maintenance mode while it runs, which is worth seeing once on staging rather than for the first time on your live website.
Once or twice a year covers most websites. More often for a store. It takes about an hour and it is the only way to know.
On the websites we look after under a WordPress care plan, restore testing is part of the work, alongside the updates and the monitoring. It becomes a routine check rather than something anyone has to remember.
What a good backup setup looks like
Stripped back, here is a setup that will hold up when you need it:
- Automated. Anything that relies on someone remembering will eventually not happen.
- Matched to the website. Weekly for a brochure site, daily for a blog, hourly for a store.
- Off-site. Stored somewhere that is not the web server, on infrastructure that can fail separately from it.
- Kept for 30 days or more. Long enough that a problem noticed late still has a clean copy sitting behind it. Every website we host keeps 30 days of nightly backups, on every plan.
- Complete. Files and database together. A database without the uploads folder rebuilds your content with every image missing.
- Tested. At least once a year, by actually restoring it somewhere.
We run backups at the hosting layer rather than through a plugin on each website. The reason is that a plugin runs inside the thing that breaks, so a website too broken to load is a website whose backup plugin has also stopped running. Backups taken by the server keep going regardless of what state WordPress is in. If your current setup is plugin-based, going off-site and tested, it is doing the job and there is no reason to change it for the sake of it.
One thing worth pairing with all of this: most restores happen because an update went wrong. Getting the update process right means reaching for the backup far less often.
Want your backups handled for you?
Backups are the definition of a task that takes an afternoon to set up and about six months to stop thinking about entirely. You then find out where you stand at the worst possible moment.
We have been building and looking after WordPress websites in New Zealand for over 15 years, across more than 800 sites. Every website we host runs nightly backups to Amazon S3, kept for 30 days, on AWS infrastructure in Auckland or Sydney. On a WordPress care plan the restore testing and the updates that make backups necessary are handled as well.
If you are not certain what your current backups do, get in touch and we will take a look and tell you what we find.
