Most WordPress backup advice is either a plugin recommendation or an enterprise lecture about 3-2-1 that nobody follows on a personal site. Here’s the version that fits one site and survives being tested.

What actually needs backing up

Item Size Can you rebuild it?
Database Tens to hundreds of MB No — this is your content
wp-content/uploads Often the largest component No
Themes and plugins Moderate Yes, if you pinned versions — but you won’t remember which
wp-config.php and .htaccess Kilobytes Only by hand, and it holds your salts and DB credentials
Server config outside the site Kilobytes No — nginx vhosts, PHP ini, cron

Backing up only the database is the common mistake. Backing up only files is worse: you keep the plugins that made the site work and lose every post.

Frequency proportional to what you’d lose

Ask what a day of lost posts costs. If the answer is “nothing, I’d rewrite it,” daily is plenty. If you publish weekly, daily is generous and cheap. If you run a store, you need hourly or point-in-time recovery, and on most managed platforms that’s a paid feature.

Where the copies go

A backup on the same server isn’t a backup. It’s a copy that dies with the thing it was protecting. Keep at least:

  • One local copy for fast restores — on the server, or a snapshot.
  • One remote copy on different infrastructure. Object storage is cheap and sufficient.
  • One copy a bad update can’t reach. Object storage with versioning or object lock covers this without tape.
Encrypt before uploading. Your database holds user emails and password hashes. Pushing unencrypted dumps to a bucket is a breach waiting for a misconfigured ACL.

Retention that doesn’t explode

A workable schedule for one site: 7 daily, 4 weekly, 12 monthly. Twenty-three restore points covering a year, costing a few gigabytes. Prune automatically — a backup directory that grows forever eventually fills the disk and takes the site down, which is the exact failure you were insuring against.

The part everyone skips: test the restore

An untested backup is a hypothesis. Once a quarter, restore somewhere disposable and confirm three things: the site loads, the latest post exists, images render.

  1. Provision a throwaway VPS or a local container.
  2. Import the dump and extract the files.
  3. Point a hosts-file entry at it and load the homepage.
  4. Check the newest post, one image, and a plugin settings screen.
  5. Delete the instance and note the date you tested.

Twenty minutes a quarter. It’s the difference between having backups and being able to recover.

What a good backup has that a bad one doesn’t

  • A log of successes, not just a schedule. Silent failures are routine: disk full, credentials expired, plugin conflict. Get notified on failure, and verify the notification arrives.
  • A documented restore path someone else could follow. If only you know it, it isn’t a plan.
  • Credentials stored separately from the backups themselves.

Questions people ask

Is my host’s daily backup enough?

Better than nothing, rarely enough alone. Host backups usually live on the same infrastructure, with short retention, and restoring may need a support ticket. Keep your own remote copy.

Do I need a plugin for this?

Not strictly. A cron job running mysqldump plus an rsync of wp-content into versioned object storage does the job and is easier to verify. Plugins are convenient and are one more thing that can break.

How much storage do backups need?

Roughly 1.5–2x your site size once compression and retention overlap are counted. Check your uploads directory size first.

Sources

Some links on this page are affiliate links. If you buy through them, TechPicks may earn a commission at no extra cost to you. It does not affect what we recommend. Full disclosure.