July 28, 2026

How to back up WordPress properly (and why most backup plugins leave you exposed)

Most WordPress owners think they have backups. What they actually have is a plugin that promised backups, dumped some files into a folder on their own server, and hasn't been checked in eighteen months. When the site gets hacked or the host has a bad day, that folder either goes down with the ship or turns out to be missing half the pieces needed to rebuild.

A backup you can't restore from isn't a backup. It's a receipt for a feeling. Let's walk through what a real WordPress backup includes, where the popular plugins quietly fail you, and how to set things up so a bad Tuesday doesn't turn into a two-week outage.

What a complete WordPress backup actually contains

A WordPress site is three separate things stitched together, and if you miss any one of them, you can't rebuild.

1. The database. This is where every post, page, comment, user account, WooCommerce order, plugin setting, and menu structure lives. Lose the database and you've lost the site — even if you still have every file. The database is a MySQL (or MariaDB) instance, and it has to be exported as a .sql dump to be portable.

2. The files. This is your /wp-content/ folder mostly — themes, plugins, uploads (all your images and PDFs), and any custom code. Core WordPress files can be re-downloaded from wordpress.org, but your uploads folder is irreplaceable.

3. wp-config.php. This one file sits at the root of your install and contains your database credentials, security salts, table prefix, and any custom constants (memory limits, debug flags, SSL settings). Restore a site without the original wp-config.php and you'll spend hours guessing what the previous setup looked like — assuming you can even reconnect to the database.

Here's the problem: a lot of backup plugins default to "files only" or "database only" unless you dig into the settings. Some skip wp-config.php because it's outside /wp-content/. If you've never opened your backup archive and looked at what's in it, you don't actually know what you have.

Quick test: download your latest backup, unzip it, and look for these three things:

A .sql file (usually a few MB to a few hundred MB)
A wp-content/ folder with your themes, plugins, and uploads
A wp-config.php file at the root

If any of those are missing, your backup is incomplete.

The fatal mistake: backups on the same server

Here's the pattern I see most often on hacked WordPress sites: the owner has a backup plugin installed, it's been running for months, and the backups are stored in /wp-content/backups/ or /wp-content/uploads/backups/.

Which is the same server that just got compromised.

When an attacker gets in — through a vulnerable plugin, a stolen admin password, or a hosting-level exploit — they have access to every file on that server. That includes your backups. On the incident response job I did for a Southern California contractor, the previous contractor had left backups sitting in a subfolder of /wp-content/. When the site was reinfected by a self-healing backdoor, those "backups" were compromised too. Restoring from them would have reinstalled the malware.

Same-server backups protect you from exactly one scenario: you accidentally delete something and want it back within a few days. They do not protect you from:

Malware infections
Ransomware
Your hosting account being suspended
The server disk failing
The host going out of business
An attacker deleting the backup folder to force you to pay

If your backups live on the site they're supposed to protect, you don't have backups.

Off-site storage: where backups actually need to go

Off-site means "on infrastructure that is not the same server, not the same hosting account, and ideally not the same company." The goal is that if your host disappears at 3 a.m., your backups don't disappear with it.

Practical options, from most to least reliable:

Cloud object storage (best). Amazon S3, Backblaze B2, Wasabi, or Google Cloud Storage. These are cheap (a few dollars a month for most small sites), redundant across data centers, and completely separate from your web host. UpdraftPlus, BackWPup, and Solid Backups (formerly BackupBuddy) all support these. Backblaze B2 is the cheapest for most small sites — around $0.006 per GB per month.

Consumer cloud (good, with caveats). Dropbox, Google Drive, or OneDrive. Fine for small brochure sites. The catch: these are tied to a personal account, which means if that account gets compromised or the person who set it up leaves the company, you may lose access. Use a dedicated business account, not someone's personal Gmail.

Hosting-level snapshots (verify before trusting). Many managed hosts (Kinsta, WP Engine, SiteGround, Cloudways) offer automatic daily snapshots. These are convenient, but ask your host directly: are snapshots stored on the same infrastructure as my site? If the answer is yes, or "I'm not sure," treat them as a convenience, not a real backup. Some hosts store snapshots in a separate region or account — those are legitimate off-site backups. Get it in writing.

The rule I use: at least two backup destinations, at least one of them completely outside your host. Belt and suspenders. Storage is cheap; downtime is not.

Retention: how many copies, how far back

Most backup plugins default to keeping the last 5 to 10 backups. For malware, that's not enough.

WordPress infections often sit dormant for weeks before activating. An attacker plants a backdoor in October, doesn't touch it, waits for you to run backups over it a dozen times, and then in December starts sending spam or injecting redirects. By the time you notice, every backup you have contains the same backdoor.

Minimum retention I recommend:

Daily backups for the last 14 days
Weekly backups for the last 8 weeks
Monthly backups for the last 6 to 12 months

That way if you discover a compromise, you have older versions to fall back to that predate the infection. This is called a grandfather-father-son rotation, and most decent backup plugins support it in their settings.

At storage prices today, keeping a year of monthly backups for a typical small-business site costs less than a cup of coffee per month. There is no good reason to skip it.

The restore test: hope is not a strategy

Here is the single biggest thing separating people who actually have backups from people who think they do:

Have you ever restored one?

Not "have you clicked the restore button on a plugin dashboard." Actually taken a backup file, moved it to a fresh environment, and stood the site back up from scratch.

Because this is what happens when you finally need to restore and haven't tested:

The .sql file is corrupted because the export timed out on a big database
The plugin's restore feature only works if you can log in to WordPress, which you can't because the site is down
The backup archive is 8 GB and your host's PHP upload limit is 128 MB
The archive is encrypted with a password nobody remembers
The plugin has been abandoned and the restore tool no longer works with current PHP versions

I've seen all five. The good news: testing a restore is straightforward.

Spin up a local WordPress environment (LocalWP is free and takes about ten minutes to install)
Download your latest off-site backup
Restore it to the local environment
Log in and verify: does the site look right? Are recent posts there? Do images load?

Do this once a quarter. If it works, you have backups. If it doesn't, now you know before it matters.

Backup frequency by risk

How often you should back up depends on how much data you'd lose in a day and how painful that would be.

E-commerce (WooCommerce, Shopify integrations, membership sites): daily minimum, ideally real-time for the database. Every order, every new customer, every inventory change is data you can't recreate. Losing 24 hours of orders is a real financial hit and a customer service nightmare. For high-volume stores, look at hourly database backups.

Content sites that publish regularly (blogs, news, media): daily. You don't want to lose a week of posts.

Brochure sites that change monthly or less: weekly is the floor. Even a static-looking site collects contact form submissions, comment spam that needs cleaning, and plugin updates. Weekly full backups plus real-time file monitoring is a reasonable posture.

Whatever cadence you pick, write it down. Set a calendar reminder to verify backups are running once a month. Automation is great until it silently fails.

A sane setup for a small business site

If you want a concrete starting point for a typical 10-to-50-employee company running a WordPress marketing site, here's what I'd set up:

UpdraftPlus (free tier is fine for most sites, Premium if you want incremental backups)
Destination: Backblaze B2 or Amazon S3, using a dedicated bucket for that site only
Schedule: Files weekly, database daily
Retention: 14 daily, 8 weekly, 12 monthly
Second copy: Enable hosting-level snapshots if your host offers them and stores them off-infra
Quarterly restore test: Restore the latest backup to a local WordPress instance and verify it works
Monthly check: Log in, confirm the last backup succeeded, look for error emails

Total cost: usually under $10/month in storage. Total time to set up: about an hour. Total peace of mind: significant.

Backups are the floor, not the ceiling

A good backup strategy means you can survive a disaster. It doesn't mean disasters won't happen. Backups don't stop malware from infecting your site in the first place — they just make sure you can recover when it does. Pair backups with real hardening (strong admin passwords, 2FA, limiting plugins to what you actually need, keeping everything updated, a web application firewall) and you're covering both prevention and recovery.

If you're not sure what you have right now — whether your backups are complete, whether they're actually off-site, whether they'd restore if you needed them — that's the kind of thing my Security Retainer handles as part of the monthly work. Backup verification, restore tests, and making sure your safety net isn't full of holes are all included. Reach out through thewizrdz.io if you'd like me to take a look.