Every business owner knows they should back up their website. Most of them haven't done it properly, or at all. And the ones who find out the hard way — through a hack, a botched update, or a hosting provider failure — tend to learn a lesson they'd pay a lot of money to unlearn.
This isn't a scare piece. It's a practical rundown of what a backup actually means, what the standard approach looks like, and how to check whether what you currently have is sufficient.
What a backup actually is — and what it isn't
A website backup is a complete, restorable copy of everything needed to rebuild your site from scratch: all files (your theme, plugins, media uploads, custom code), your database (all content, settings, user accounts, orders, form submissions), and ideally your configuration files.
What it is not:
- A hosting snapshot — many hosts take periodic server snapshots. These are better than nothing, but they're stored on the same infrastructure as your live site. If the hosting provider has a major failure, both your site and the snapshots go down together.
- A static copy of your homepage — a screenshot or a cached version of your front page won't restore a database full of customer orders or 5 years of blog content.
- "The developer has a copy" — maybe they do, maybe they don't. Either way, their copy is probably not current, and you have no idea when it was last updated or whether it's complete.
The most common mistake: Businesses discover their "backups" are either missing the database, stored only on the hosting server that just failed, or haven't run successfully in months — and they only find out when they need them. A backup that hasn't been tested is not a backup. It's a hope.
The 3-2-1 backup rule
The 3-2-1 rule is the standard framework used by IT professionals and data protection teams worldwide. It's simple:
- 3 copies of your data — the live site plus two backups
- 2 different storage media — e.g., your hosting server and an external cloud storage service
- 1 copy offsite — physically or logically separate from the others, so a single failure event can't wipe everything
For a WordPress site, this might look like: daily automated backups to your hosting account's backup folder (copy 1), plus automated syncing of those backups to an Amazon S3 bucket or Google Drive (copies 2 and 3). The offsite copy means that even if your hosting provider has a catastrophic failure, your data is recoverable.
What you actually lose without a working backup
People tend to think of a crashed website as a temporary inconvenience — a few hours of downtime while the developer sorts it out. The reality is more costly than that.
Without a recent, complete backup, you can lose:
- Orders and transaction records — if you're running any kind of e-commerce or taking bookings through your site, unrecoverable data means unrecoverable revenue and potential legal complications
- Customer data — contact form submissions, email opt-ins, account registrations. Under the NZ Privacy Act 2020, you have obligations around the security and retention of personal information. Losing it through negligence is a compliance issue, not just a technical one.
- SEO history — a website that's been down for days gets crawled and re-evaluated by Google. Pages that disappear from the index take time to recover, even after the site comes back. For businesses that depend on organic search traffic, this is real revenue lost.
- Content investment — years of blog posts, product descriptions, custom images, configuration work. Rebuilding this is expensive and time-consuming.
How often should backups run?
The answer depends entirely on how often your site changes and what you can afford to lose.
- Daily backups — appropriate for most business websites, especially those with regular content updates, contact form activity, or any transactional functionality
- Real-time or hourly backups — necessary for e-commerce sites processing daily orders. Losing 24 hours of orders because a backup only runs once a day is not acceptable.
- Weekly backups — only appropriate for completely static sites that change rarely, with no transactional data
Most modern backup plugins for WordPress (such as UpdraftPlus, BlogVault, or JetBackup on cPanel-based hosting) support scheduled daily backups with offsite syncing at minimal cost — typically NZD $5–$15 per month for a robust setup.
Don't just keep the last backup — keep 30 days of history. Malware infections often sit dormant for weeks before activating. If you only keep 3 days of backups and the infection started 2 weeks ago, all three backups are compromised. Thirty days of retention is the practical minimum for meaningful recovery options.
Where to store them
The short version: not only on the same server as your live site. Offsite options include:
- Amazon S3 — highly reliable, inexpensive for small sites (typically under NZD $2/month for a few GB)
- Google Drive or Dropbox — easy to set up, most backup plugins support direct integration
- A dedicated backup service — providers like BlogVault or ManageWP handle the whole process, including offsite storage, for a flat monthly fee
Don't store backups solely in your hosting control panel's "backup" folder. If the server goes down, so does the folder. The whole point of offsite storage is physical and logical separation.
How to test a restore (and why almost nobody does it)
Running backups is step one. Testing restores is what most businesses skip, and it's where the actual confidence in your backup strategy lives.
At a minimum, once every three months, do a restore test. This doesn't mean restoring over your live site — it means:
- Download a recent backup file to your local machine and verify it's complete (files + database)
- Set up a staging environment (most decent hosts offer this) and restore the backup there
- Browse the staging site and confirm it looks and functions correctly
- Check that forms work, any payment functionality works in test mode, and that the database content (posts, pages, settings) is intact
If this process takes more than 30 minutes, you'll need to streamline it — but the first time through is worth every minute. An untested backup has unknown reliability. A tested backup is something you can actually count on.
The maintenance reality
A good backup system runs automatically, gets checked occasionally, and costs a small amount per month. The alternative — rebuilding a site from scratch after a disaster — costs anywhere from NZD $3,000 to NZD $15,000+ in developer time, plus the downstream cost of downtime, lost data, and damaged customer trust.
This is the cheapest insurance your business can buy.
We build sites with proper backup strategies included from day one. No guesswork, no hoping the host "has something." If you want to know what your current setup is actually backing up, let's have a look.
Book a free call →