Blog Backup Basics: What to Save Before You Break the Site

A blog backup is not a zip you hope is fine. It is a kit you have opened on a spare URL.

This page is the Restore Kit. It is not managed WordPress hosting and not a hosting scorecard. Those decide where the site lives. This decides whether you can survive a bad plugin update on a Tuesday. It is also not a WordPress staging tutorial. Staging is where you test a change. A backup is what you roll back to after the change already broke production.

WordPress is the usual case here. Ghost and static sites still need the content store plus the theme—same idea, fewer folders.

Disclosure: Backup plugins and hosts are commercial. CashPilot may earn a commission through links we add later. No invented “99.99% restore” claims.

Table of contents

1. What a backup is not
2. The three pieces people forget
3. The Restore Kit
4. When to run a backup
5. A test restore that proves the kit
6. Where fake backups fail
7. FAQ

What a backup is not

Tools → Export in WordPress gives you posts and pages in XML. That is useful for moving copy. It is not a Restore Kit. Media files, plugin settings, and most of wp-content stay behind.

A host snapshot can be a real kit if it includes files, database, and config. It is still incomplete until you have downloaded one copy and restored it once. A plugin email that says “backup complete” without a file you can open is a notification.

Official process: WordPress.org — backing up your site. Files and the database are two parts. Downloading the WordPress directory does not dump MySQL for you.

The three pieces people forget

Typical backup order from the handbook: export the database first, then zip the files, and keep both in one dated folder. Typical restore order: files first, then import the database, then fix wp-config if credentials changed.

For HTTPS cleanup that rewrites URLs, back up before search-replace. See mixed content / HTTPS.

The Restore Kit

              RESTORE KIT
  ┌────────────────────────────────────────────┬───┐
  │ Files zip dated (uploads included)         │ □ │
  │ Database export dated                      │ □ │
  │ Secrets copied to a password manager       │ □ │
  │ Off-site copy (drive / object storage)     │ □ │
  │ Test restore on a spare URL this month     │ □ │
  └────────────────────────────────────────────┴───┘
  5/5 = you may click Update

WordPress suggests keeping several recent sets in different places. You do not need a museum of zips. You need enough history that a bad Tuesday does not overwrite the only good Friday.

If you use Cloudflare, a backup is still on the origin. The CDN will not reconstruct your database. See Cloudflare for small blogs.

When to run a backup

• Before WordPress, theme, or plugin updates
• Before a host move (Bluehost alternatives if that is why you are leaving)
• Before a search-replace on URLs
• Weekly if you publish more than you can rewrite from memory

High-activity sites (payments, memberships, daily posts) often need a daily dump as well. That is volume, not a ranking trick.

A test restore that proves the kit

1. Create a spare URL—temporary domain, subdomain, or a host clone you will delete.
2. Upload files. Import the database. Point wp-config at the new database name and password.
3. Open a post that has images. Click three images. Log into wp-admin. Submit a comment or a form if you have one.
4. If that works, the kit is real. If not, fix the kit now, not during an outage.

You do not need a permanent staging product for this drill. If your host already offers a clone button, use it for updates—that job lives on the staging post. Here the clone only proves last week’s zip opens.

Then go back to publishing. How often should you publish still matters more than a prettier backup dashboard.

Where fake backups fail

Missing uploads. The dump restored, the theme loaded, every hero image 404s. The zip never included wp-content/uploads.

Database skipped. You copied files over FTP and called it a backup. The posts never left the old MySQL.

Secrets still point at production. The restore looks empty because wp-config is talking to the live database, or the salts do not match what the dump expects.

Serialized URLs after a move. Search-replace that is not WordPress-aware can break plugin options. If you are changing hosts, finish the Restore Kit first, then treat URL rewrite as a separate, backed-up step.

If the Restore Kit is 5/5, update the plugin. If it is not, do not click Update—finish the kit first.

FAQ

What should a small blog back up?

Files, database, and secrets. WordPress posts live in the database, not in the theme folder. A folder zip without a dump is incomplete.

How often should I back up?

Before updates, and weekly if you publish often. Daily is reasonable if you cannot afford to rewrite a week of posts. Off-site copies beat a perfect calendar.

Is a host backup enough?

Only if you have restored it once and you also keep a downloaded copy. Same-disk snapshots fail with the disk.

Is this a hosting guide?

No. This is only the Restore Kit. Host pick and managed WordPress are other URLs.

Do I need a paid backup plugin?

Not on day one. Paid tools help schedules and off-site storage—verify on the vendor’s official page.

What is a test restore?

You load the backup somewhere and confirm posts, images, and login work. An unopened zip is not proof.

Should I back up before changing hosts?

Yes. Keep the old plan paid until the new origin works. Export files and database first.

Where do backups fail most often?

Missing uploads, skipped database, or secrets pointing at the old database. Serialized old URLs are next after a hostname change.