How to Backup WordPress Properly: The Strategy, Not Just the Plugin

Most guides on how to backup WordPress hand you a plugin and call it done. Install UpdraftPlus, click Backup Now, store it on Google Drive. That works right up until the day you actually need it, and the backup is six weeks old, sitting on the same server that just died, or missing the database. We’ve cleaned up enough of those mornings to know the plugin is the easy part. The strategy is what saves you.

This is how we set up backups for client sites we maintain, why we do it that way, and the mistakes that turn a “backup” into a false sense of security.

A WordPress backup is two things, and people forget one

Your site lives in two places. The database holds your posts, pages, comments, users, and settings. The files hold WordPress core, your theme, your plugins, and everything in the uploads folder: images, PDFs, downloads. A real backup captures both. Miss the database and you keep your photos but lose every article. Miss the files and you keep your text but every image is a broken link.

The single most common broken backup we see is a database-only export someone pulled from phpMyAdmin and assumed was “the site.” It isn’t. When you decide how to backup WordPress, the first question is always: does this method grab both halves? If you can’t answer yes, it’s not a backup.

The 3-2-1 rule, translated for WordPress

Sysadmins have a rule we wish more WordPress guides repeated: keep three copies of your data, on two different types of storage, with one copy off-site. It sounds like overkill for a blog. It isn’t, and here’s what it means in plain WordPress terms.

• Three copies: the live site, plus two backups. Not one. One backup means a single corrupted file or failed upload leaves you with nothing.
• Two storage types: for example, your host’s snapshot system and a separate cloud destination like Google Drive, Dropbox, or Amazon S3. Different systems fail in different ways.
• One off-site: at least one copy not on the same server as your site. If the server burns down, and servers do, a backup stored on that same server burns with it.

That last point is the one that bites people. A backup sitting in /wp-content/backups/ on the same hosting account is convenient and almost worthless for disaster recovery. The whole reason you back up is to survive the server failing, and that copy fails with it.

Method 1: a plugin to off-site storage (what we use for most sites)

For the majority of small and mid-size sites, a backup plugin pushing to cloud storage is the right answer. It’s automatic, it grabs files and database together, and it sends the copy somewhere off the server. Our default is UpdraftPlus. Not because it’s magic, but because it’s been stable for years, restores cleanly, and the free tier already does scheduled backups to remote storage.

The setup that matters: install UpdraftPlus, go to its Settings tab, and connect a remote destination. Google Drive and Dropbox are the easiest, Amazon S3 if you want more control. Set a schedule for both files and database. Then set retention to keep several copies, not one. A common default is “keep 1 backup,” which quietly overwrites your only good copy with a broken one the moment something goes wrong. Keep at least the last 5 to 7.

BackWPup and Solid Backups (formerly BackupBuddy) do the same job; pick one and learn it well rather than installing three. The plugin you understand beats the plugin with the best feature list. For the full ranking of these plugins by which restore actually works under pressure, see our best WordPress backup plugin comparison.

Method 2: your host’s backups, useful but not the whole plan

Hostinger, SiteGround, Bluehost, Kinsta, and most managed hosts take daily snapshots automatically. This is genuinely good, and on managed hosting like Kinsta or WP Engine the snapshots are reliable enough that we lean on them as one of our copies. But host backups have three limits worth knowing before you trust them alone.

• They’re on the same provider. If your account is suspended or the host has a bad day, your backups can be locked behind the same door as your site.
• Retention is short. Many shared hosts keep snapshots for 7 to 30 days. If a problem crept in two months ago, the clean version may already be gone.
• Restores are often all-or-nothing. You usually can’t pull back a single page or one plugin; you roll the entire site to a point in time and lose anything published since.

Use the host backup. Just don’t make it your only backup. It’s copy number one of three, not the whole strategy.

Method 3: the manual backup, for when you can’t reach the dashboard

Sometimes the site is down or locked and a plugin isn’t an option. The manual route still works, and every site owner should know it once. There are two parts, matching the two halves of your site.

For the files: log into your host’s cPanel or control panel, open the File Manager, go to the site root (usually public_html), select everything, compress it to a .zip, and download it. An FTP client like FileZilla does the same job if you prefer. For the database: open phpMyAdmin from your control panel, select your WordPress database, click the Export tab, choose the Quick / SQL option, and download the .sql file. Keep the two files together and dated. That pair is a complete backup.

If you’re comfortable on the command line, WP-CLI makes this two commands, wp db export and a tar of the files, which is how we script backups before risky changes. For a site move, the same care applies; our walkthrough on migrating WordPress without downtime leans on a fresh, tested backup as the rollback plan.

The step everyone skips: restore a backup before you need to

Here’s the uncomfortable truth almost no guide mentions. A backup you have never restored is not a backup. It’s a hopeful guess. We’ve watched site owners discover, mid-crisis, that their nightly backups had been silently failing for months, or that the file restored but the database wouldn’t import. The time to find that out is not while your site is down.

So test it. Spin up a free local environment with LocalWP or a staging site (most managed hosts give you one click), and restore your latest backup there. Confirm the homepage loads, you can log in, and a recent post is present. Do this once when you set backups up, and again any time you change hosts or plugins. Ten minutes now buys you certainty later.

How often should you back up?

Match the schedule to how often your site changes, not to a calendar someone else picked. The real question is: if you lost everything since the last backup, how much would that hurt?

• A brochure site that rarely changes: weekly is fine, plus a manual backup before any update.
• A blog publishing a few times a week: daily backups, so you never lose more than a day of writing.
• A WooCommerce store taking orders: real-time or hourly. An order lost is a customer and money lost. This is where a service like Jetpack VaultPress Backup, which records every change, earns its fee.

And always, always take a fresh backup right before you update WordPress core, a theme, or a plugin. Updates are also where security and stability meet, which is why keeping everything current is the top item in our WordPress security best practices. They are the single most common reason a site breaks, and a two-minute backup beforehand turns a disaster into a thirty-second rollback.

Want backups handled, monitored, and actually tested?

Setting backups up is a good afternoon’s work. Keeping them honest, checking that they ran, that they’re off-site, that they still restore, is the part that quietly slips when you’re busy running a business. That’s a chunk of what our WordPress maintenance service covers: scheduled off-site backups, update management with a backup before every change, and uptime monitoring so we hear about problems before you do. If your site is already broken and you need someone to recover it, our WordPress audit and recovery is the faster call.

Frequently asked questions

What is the easiest way to backup a WordPress site?

Install a backup plugin like UpdraftPlus, connect a cloud destination such as Google Drive or Dropbox, and set a schedule that backs up both files and database. It’s automatic, it stores the copy off your server, and the free version handles everything most sites need.

How do I backup my entire WordPress site manually?

Two parts. Download all your files from the site root (usually public_html) using cPanel File Manager or FTP, compressed to a zip. Then export your database from phpMyAdmin as an SQL file. Keep both files together and dated, and that pair is a complete manual backup.

Is my host’s backup enough on its own?

Not on its own. Host backups are useful but they sit on the same provider, often keep only 7 to 30 days, and usually restore all-or-nothing. Treat your host backup as one copy and keep a second, off-site copy through a plugin so you’re never depending on a single system.

How often should I back up WordPress?

Match it to how often the site changes. Weekly for a static brochure site, daily for an active blog, and hourly or real-time for a store taking orders. On top of the schedule, always take a manual backup right before updating core, a theme, or a plugin.

How do I restore a WordPress backup?

If you used a plugin like UpdraftPlus, open its settings, find the backup in the list, and click Restore. For a manual backup, upload the files back to the server and import the SQL file into your database via phpMyAdmin. Test the restore on a staging site first so you know it works before you need it.