How to Back Up a WordPress Site Properly (and Restore It After a Failed Update)

There’s a specific kind of panic that hits when you click “Update” on a plugin and your site comes back as a white screen — or doesn’t come back at all. If you’re reading this before that happens, you’re in the best possible position: a proper backup turns a broken site from a disaster into a ten-minute fix. If you’re reading this after it happened, skip ahead to the restore section — we’ll get you through it.

This guide is for site owners, freelancers, and small teams who run WordPress and want a backup setup that actually works when tested — not just a plugin icon that says “backup complete.” You’ll learn exactly what a complete WordPress backup must contain, how to set up automatic backups the right way, how to restore after a failed update, and why managed hosts like Kinsta and Cloudways handle most of this for you at the server level.

By the end, you’ll have a written checklist you can run in under 15 minutes, plus a tested restore path — because a backup you’ve never restored is just a hope.

Table of Contents

• What a complete WordPress backup actually includes
• Step 1: Decide your backup frequency
• Step 2: Set up automatic backups
• Step 3: Keep copies in more than one place
• Step 4: Back up manually before every update
• Step 5: Restore after a failed update
• The 15-minute backup checklist
• Common mistakes and troubleshooting
• FAQ
• Conclusion
• Sources

What a complete WordPress backup actually includes

According to the official WordPress documentation, a WordPress site is stored in two separate places, and both must be backed up [1]:

1. The database — your posts, pages, comments, settings, and user accounts live in a MySQL/MariaDB database. Backing up files alone does not include the database.
2. The files — WordPress core, your theme, plugins, uploaded media, and configuration files like wp-config.php.

A “backup” that captures only one of the two is incomplete. If your current backup plugin or host snapshot doesn’t explicitly cover both, that’s the first thing to fix.

Managed hosts go further. Kinsta’s automatic backups, for example, are full environment snapshots that include files, database, redirects, and server configuration — so a restore brings back the whole working state, not just the WordPress folder [2].

Step 1: Decide your backup frequency

The official WordPress guidance ties frequency to how much data you can afford to lose [1]:

Site type	Recommended frequency
Brochure site, rarely updated	Weekly
Blog publishing a few times a week	Daily
WooCommerce / membership / high activity	Daily at minimum; hourly if orders or user data change constantly
Any site, right before an update	Always take a fresh manual backup

Managed hosts map onto this neatly:

• Kinsta takes automatic daily backups on all plans, retained for 14 or 30 days depending on plan tier, and offers 6-hour and hourly backup add-ons for high-change sites [2].
• Cloudways lets you schedule server-level backups at any frequency from every 1 hour up to every 7 days, with on-demand backups whenever you want one [3][4].

Step 2: Set up automatic backups

You have three main options. Pick one primary method, then add a second layer (Step 3).

Option A: Host-level automatic backups (recommended primary)

If you’re on managed hosting, this is already running — verify it rather than assuming it.

On Kinsta:

1. Log in to MyKinsta and open Sites → your site → Backups.
2. Confirm daily backups are listed under the Daily tab. Every backup is a complete snapshot of files, database, redirects, and server config [2].
3. If your site changes hourly (e.g., WooCommerce), enable the hourly backup add-on — daily backups continue alongside it [2].

On Cloudways:

1. In the platform, go to Server Management → Backups.
2. Set your backup frequency (1 hour to 7 days) and retention period [3].
3. Before big changes, use on-demand backup from the application’s Backup & Restore panel [4]. Note: Cloudways recommends longer frequencies (12h+) for servers over ~100 GB, since very frequent backups can strain large servers [3].

Option B: A backup plugin

If you’re on shared hosting without reliable host backups, use a reputable backup plugin from the WordPress plugin directory that explicitly backs up both database and files, and schedules automatically — the official documentation recommends verifying that scheduled backups are actually completing rather than trusting them blindly [1].

Option C: Manual backups

The traditional method from the WordPress docs: download files via SFTP/FTP and export the database via phpMyAdmin in your hosting control panel [1]. It works, but nobody does it consistently — treat it as a supplement, not your system.

Step 3: Keep copies in more than one place

The WordPress documentation recommends keeping at least three recent backups, stored in different locations — for example: your hosting server, cloud storage, and your local computer [1]. A backup stored only on the same server as your site disappears with the server.

Two easy ways to get offsite copies:

• Kinsta downloadable backups: generate a ZIP archive (files + database SQL) once per week and store it locally or in your own cloud storage. Kinsta also offers external backups pushed automatically to your own Amazon S3 or Google Cloud Storage bucket on a weekly or monthly schedule [2].
• Plugin-to-cloud: most backup plugins can push archives to Google Drive, Dropbox, or S3.

Step 4: Back up manually before every update

This is the habit that saves sites. Before updating a plugin, theme, or WordPress core:

1. Take a fresh manual/on-demand backup. On Kinsta: Backups → Manual → Back up now (you can keep up to 5 manual backups, stored for at least 14 days) [2]. On Cloudways: Application → Backup & Restore → Take Backup Now [4].
2. Update on staging first if you have it. Both Kinsta and Cloudways provide staging environments; test the update there, then push to live.
3. Update one thing at a time on the live site, checking the front end after each update — so if something breaks, you know exactly which update caused it.

Kinsta also creates automatic system-generated backups around plugin/theme updates performed through its dashboard, kept for a short window (hours to days depending on update type) — a useful extra safety net, but too short-lived to rely on as your only pre-update backup [2].

Step 5: Restore after a failed update

The update broke your site. Here’s the calm path back.

If you’re on managed hosting (fastest)

Kinsta:

1. In MyKinsta, go to Sites → your site → Backups.
2. Find the most recent backup taken before the failed update.
3. Click Restore to, and choose Staging first if you want to verify the backup is good before touching live — or Live if the site is down and speed matters.
4. Confirm. Kinsta automatically generates a fresh backup of the current (broken) state just before restoring, so you can roll forward again if needed [2].
5. After restore, all files, database content, redirects, and settings are rolled back to the backup’s timestamp [2] — so any content created after that point needs re-adding.

Cloudways:

1. Go to Application Management → Backup & Restore.
2. Pick the restore point — with hourly backups enabled you can restore to a time-specific point, minimizing lost work [4].
3. Click Restore Application Now and wait for completion before testing.

If you’re restoring manually from an archive

Per the WordPress documentation’s restore order: upload the files first (via SFTP), then import the database (via phpMyAdmin) [1]. Reversing the order can leave a mismatched state.

After any restore

• Clear all caches (host cache, plugin cache, CDN).
• Test the front end, admin login, and — on stores — a checkout.
• Identify what broke, and retry the update on staging before attempting it live again.

The 15-minute backup checklist

Run this today, then quarterly:

• Automatic backups are ON and I’ve confirmed the latest one exists (not just “scheduled”).
• Backups include both database and files.
• Frequency matches how often my site changes (daily minimum for active sites).
• At least one backup copy lives off my hosting server (local ZIP, S3, or cloud drive).
• I know exactly where the restore button is and who has the login.
• I’ve done one test restore to staging, so I know the backups actually work.
• “Manual backup before every update” is written into my update routine.

Common mistakes and troubleshooting

These are patterns commonly reported by WordPress users in community forums — labeled as user reports, not official documentation:

• Users report backup plugins silently failing on large sites — scheduled backups time out or produce incomplete archives on shared hosting, and nobody notices until restore day. Fix: periodically open the backup file list and verify recent archives exist and have plausible sizes; prefer host-level backups where the process runs at server level.
• Users report restoring the wrong direction — restoring a newer backup taken after the site broke, which restores the broken state. Fix: check backup timestamps against when the failed update happened before clicking restore.
• Users report losing orders/comments after a restore — anything created between the backup and the restore is rolled back. Fix: on busy sites, use hourly backups (Kinsta add-on, or Cloudways 1-hour frequency) so the rollback window is small [2][3].
• Backups stored only on the server — a server-level failure takes the site and its backups together. Fix: Step 3 above; the WordPress docs’ three-copies-in-different-places rule exists for exactly this reason [1].
• Never testing a restore — the most common failure of all. A quarterly test restore to staging costs 15 minutes and removes the single biggest unknown.

FAQ

How often should I back up my WordPress site? Official WordPress guidance: match frequency to activity — weekly for low-traffic sites, daily for active ones — and always back up before an upgrade [1]. Stores and membership sites should consider hourly.

Do I need a backup plugin if my host does backups? Not necessarily, but you do need an offsite copy. If your host (like Kinsta) can push backups to your own S3/Google Cloud bucket or give you downloadable archives [2], that covers it without a plugin. On hosts without solid backups, a plugin is your primary tool.

Will restoring a backup delete my recent content? Yes — a restore rolls the site back to the backup’s timestamp, including posts, comments, and orders created after it [2]. That’s why frequent backups matter on busy sites.

Can I restore just the database or just the files? With manual archives, yes — the two are separate, and the WordPress docs describe handling them independently [1]. Host one-click restores typically roll back the full snapshot; Kinsta’s external backup option lets you choose files only, database only, or both when exporting [2].

What should I do the moment an update breaks my site? Don’t keep clicking things. Take note of the time, confirm which backup predates the update, restore it (to staging first if the site is only partially broken), clear caches, and test. Then retry the update in staging to find the conflict.

Conclusion

A proper WordPress backup setup is three habits: automatic backups that cover database and files, at least one copy stored away from your server, and a fresh manual backup before every update. Everything else is detail.

The honest recommendation: if backups are something you keep meaning to sort out, moving to managed hosting removes the problem entirely. Kinsta runs automatic daily full-site snapshots on every plan with one-click restore to staging or live, and Cloudways gives you scheduling from hourly to weekly with on-demand backups before every change. Either way, a failed update stops being an emergency and becomes a minor rollback.

Ready to stop worrying about failed updates? Check out managed WordPress hosting with automatic daily backups here.