Troubleshooting guide · migration-hosting · Published 2026-08-16 · 4 min read
Back up before site changes
Back up before site changes: what must be in the backup, how to test it restores, and the change sequence that stays safe.
- ·What the change needs
- ·What a good backup has
- ·The restore test
The rule is simple: before any change, take a point-in-time copy you have proven you can restore. A plugin update that breaks the site, a theme change that blanks the front end, or an image library migration that corrupts data is survivable in minutes when you have a clean snapshot, and it is an afternoon of digging when you do not. Backups are the undo button for the operations that have none.
When you must back up first
Any of these crosses the line from "safe" to "you need a copy":
- A plugin or theme update (core updates too, on a site where a theme hooks deep).
- A database operation: a search-replace, a mass edit, a cleanup, a table drop, or a schema change from a plugin.
- A code change by hand: a tweak to
functions.php, a config file, or a.htaccess. - A migration or a staging-to-live copy where failures are common; see the host migration checklist.
What a good backup has
A site backup is two halves, and both must be present and matching.
| Half | What is inside | Why it breaks if missing |
|---|---|---|
| Files | Whole doc root, incl. wp-content/uploads | The media and theme edits are pixels, not code |
| Database | One full dump, not a partial filter | The content lives here; plugin tables come along |
Each half also needs metadata: the site URL that was in use at backup time (restoring into a different domain needs a search-replace, which the WordPress restore article covers), the backup date, and the plugin stack state.
Before you even make the copy
Short checklist that costs seconds and saves hours:
- Disable the change you are about to do first: turn off the update, hold the deployment, and run a smoke test before you touch a file.
- Take the copy at a quiet moment. The database should be quiescent for the full dump; a change mid-write is exactly the state you are backing up.
- Store it offsite, out of the web root, and where a human can reach it from outside the host (an S3 bucket on a different account, a zip away from
uploads).
A variant gets you no points: a plugin that backs up nightly but the restore silently punches the wrong folder, or a host backup that expires at 14 days with the change made on day 13.
The restore sequence
When the change fails:
- Say "no" to one-click restore first. Test the restore on a staging copy before the live one, and only then push the live file-and-db restore together.
- Restore both halves. Files first, then the database upon a clean app boot, and in that order if the copy is fresh; the content and file versions must match.
- After the restore, revert the change flag, clear the cache, and verify the site boots with no
fatalin the error log. - Prove the restore before you need it. A monthly practice: restore last week's backup into a scratch domain, hit the homepage, log in, post one page. Twenty minutes that buys you a proven restore.
The rule of three
Keep three copies total: the current snapshot, the before-the-change copy you made five minutes ago, and a dated weekly. Offsite plus local keeps a single host outage from taking all three.
When to involve a professional
If the site runs in production money flows, a payment gateway, or a live client contract, test restore is part of the service, not a weekend task. Have a professional verify the backup and run the drill at least quarterly, and never trust a "backup exists" email from a host when you have never restored from it.