WordPress backup guide: never lose your website again

What does a complete WordPress backup include?

A complete backup includes all files (wp-content: themes, plugins, uploads) plus the full database (posts, settings, users, orders) — and ideally wp-config.php and .htaccess. Files without the database are a hollow shell; the database without files is content with no site. Both, every time, or it's not a backup.

WordPress stores your site in two places, and beginners back up only one:

• Files (wp-content/): themes, plugins, and uploads (every image and document in your media library). This is the big part — often gigabytes.
• Database: posts, pages, comments, settings, users, WooCommerce orders — everything you created in the dashboard. Usually tens of megabytes, but it's the irreplaceable part.
• Configuration: wp-config.php (database credentials, keys) and .htaccess/nginx rules. Small, critical, often forgotten.
• Not needed: WordPress core itself — it's freely re-downloadable and identical everywhere. Good backup tools exclude it to save space.

The failure modes of partial backups: backing up only files means losing every post and order when disaster strikes; backing up only the database means losing every uploaded image. 'My host backs up' often means files-only or 7-day retention — verify scope explicitly, in writing, before trusting it.

For WooCommerce, the database is money: orders, customers, stock levels. A store needs more frequent database backups than a brochure site — hourly or real-time for busy stores, because a day-old backup means a day of lost orders.

Size reality check: check your wp-content/uploads size today. If it's 15 GB of unoptimized images, your backup strategy must handle 15 GB — or better, compress those images (the image compressor shrinks libraries dramatically) so backups stay fast and cheap.

How often should WordPress be backed up?

Match frequency to change rate: daily automated backups for active sites and stores, weekly for rarely-changed brochure sites, plus a manual backup before every update, migration or major edit. Database-only backups can run more often than full ones for busy WooCommerce stores.

Schedules by site type:

• WooCommerce / membership / active blog: daily full backups, retained 30 days. Busy stores: add frequent database backups (hourly or real-time incremental).
• Business brochure site (changes monthly): weekly full backups, retained 8–12 weeks.
• Portfolio / static-ish site: weekly or biweekly, retained 2–3 months.
• Always, regardless: manual backup before core/plugin/theme updates, before migrations, before major content edits, and before handing access to a developer.

Retention matters as much as frequency. Hacks often go unnoticed for weeks — if you keep only 7 days of backups, every copy may contain the malware. Keep 30 days minimum for active sites; the storage cost is trivial compared to a reinfected restore.

Automate relentlessly. Manual backups fail because humans forget — every disaster story starts with 'I meant to'. A backup plugin or host-level automation running on schedule, emailing you on failure, is the only system that survives contact with a busy life.

Time the backups sanely: run full backups in low-traffic hours (they load the server), and stagger them away from other cron jobs. A backup that crashes the site at noon from resource exhaustion is worse than no backup that day — schedule smart.

Where should WordPress backups be stored?

Follow the 3-2-1 rule: 3 copies of data, on 2 different media, with 1 off-site. For WordPress this means: the live site, automated backups on the server, plus copies in independent cloud storage (Google Drive, Dropbox, S3). A backup on the same server that dies with the site is not a backup.

The 3-2-1 rule applied to WordPress:

• Copy 1: your live site (counts as one copy — barely).
• Copy 2: automated backups stored on the hosting account — protects against your own mistakes (bad update, deleted content) but not server failure.
• Copy 3: backups pushed automatically to independent cloud storage — Google Drive, Dropbox, Amazon S3, or Wasabi. This is the copy that survives hosting company disasters, account suspensions and ransomware.

Most backup plugins (UpdraftPlus, BlogVault, Jetpack Backup) push to cloud storage automatically — configure this on day one, not 'later'. Verify the cloud destination actually receives files: open the Drive folder and see dated backup archives sitting there. An unconfigured destination setting is the most common silent failure.

Security note: backups contain everything — database credentials in wp-config, customer data, admin password hashes. Cloud backup destinations must be private (not shared links), and the storage account itself needs 2FA. An unprotected backup archive is a skeleton key to your site; treat it like one.

For the truly cautious: keep one periodic copy somewhere entirely separate — a quarterly download to an external drive. Cloud accounts get locked, subscriptions lapse; the external drive is your backup's backup. Paranoia is cheap here.

Which backup plugin should you use?

UpdraftPlus (free) covers most sites well with scheduled backups to cloud storage and straightforward restores. BlogVault and Jetpack Backup (paid) add real-time backups and one-click restores ideal for WooCommerce. Your host's built-in backups are a useful second layer, not a primary — verify their scope and retention before relying on them.

UpdraftPlus — the free standard. Scheduled full and database backups, push to Google Drive/Dropbox/S3, restore from the dashboard. The free tier handles single sites completely; premium adds incremental backups and multisite. Start here unless you have a reason not to.

BlogVault / Jetpack Backup — paid, and worth it for stores. Real-time (per-change) backups mean a busy WooCommerce site never loses an order, and one-click staging restores make recovery dramatically less stressful. When downtime costs money, this is the tier to buy.

Host-provided backups — convenient second layer, but interrogate them: full or partial? How many days retained? One-click restore or ticket-to-support? Stored off-server? 'We back up daily' has meant everything from excellent to useless — get specifics.

Manual backups (SFTP + phpMyAdmin export) — every owner should know how, as a fallback when plugins fail. But as a *system*, manual is a failure waiting for a busy week. Automate the routine; keep manual as the emergency skill.

Whatever you choose, the plugin decision matters less than the system: automated + off-site + tested restores. A perfectly configured UpdraftPlus beats an expensive tool nobody verified.

How do you test that backups actually work?

Test restores quarterly: restore a backup to a staging subdomain and verify the site loads, logins work and recent content exists. Also verify backup *completion* weekly via email reports or the cloud destination. An untested backup is a hope — restores fail from corrupted archives, incomplete uploads and expired credentials more often than people expect.

The restore test, step by step:

• 1. Create a staging subdomain (staging.yoursite.com) — most hosts offer one-click staging; it keeps tests off your live site.
• 2. Restore your latest backup there using the plugin's restore flow. Note every step and any error.
• 3. Verify: homepage loads, you can log in, recent posts/pages exist, images display, forms submit. Compare against live.
• 4. Record the result — date, backup used, issues found. This log is gold during a real disaster.
• 5. Fix what failed — then re-test. A test that fails is the test working as intended.

Between full tests, monitor continuously: enable the plugin's email notifications and actually read them (a month of silent backup failures is a classic disaster prelude), glance at the cloud destination monthly to confirm fresh archives, and re-verify after any credential change (new Drive password? the backup plugin's token may have died with it).

Common restore failures and preventions: corrupted archives (verify checksums / test-extract periodically), incomplete uploads to cloud (check archive sizes — a 50 MB backup where 2 GB is expected screams failure), PHP timeouts on large restores (restore via host tools or in parts for huge sites), and expired storage tokens (re-authenticate cloud connections yearly).

Schedule it: put 'backup restore test' in your calendar quarterly, alongside plugin updates. Pair it with the broader maintenance routine — updates, backups, security scan, performance glance, one sitting, four times a year.

How do you restore WordPress from a backup?

For a broken-but-accessible site: use the backup plugin's one-click restore from the dashboard. For a dead site: reinstall WordPress fresh, install the backup plugin, connect it to your cloud storage, and restore from there. For hack recovery: restore a backup from before the infection date, then close the entry point — restoring without fixing the vulnerability just schedules the next hack.

Scenario-based restore procedures:

• Bad update (site broken, dashboard works): plugin restore → select the pre-update backup → restore → verify. Ten minutes, minimal drama. This is why you back up *before* updating.
• White screen / dead site: fresh WordPress install on the host (or a new host), install your backup plugin, link cloud storage, restore. Your content and settings return; core is fresh and clean.
• Hacked site: identify the infection date from file modification times, restore the newest backup *older* than that date, then immediately harden (see the security guide) — outdated plugin? weak password? Close it before going live. If every backup is infected, professional malware removal is safer than DIY.
• Moving hosts: restore the backup onto the new host — many backup plugins double as migration tools. Then follow the migration checklist for DNS and verification.

During any restore: put up a maintenance page, warn stakeholders of the recovery point ('we're restoring to Tuesday 2 AM — Wednesday's changes will need re-entry'), and after restoring, immediately take a *fresh* backup of the working state. Restores are stressful enough without discovering the restore itself wasn't backed up.

WooCommerce special case: restoring a day-old backup loses a day of orders. Reconcile after restore — export orders from payment gateway records (Stripe/PayPal dashboards retain them) and re-enter what's missing. This is why busy stores need real-time backups: the restore gap is measured in orders, not hours.

Frequently asked questions