Restoring a Website From Backup Without Turning One Problem Into Two

Identify the point in time things last worked correctly by checking error logs and recent changes — a plugin update, a theme edit, a content change — and pick the backup version from just before that point. Restoring too far back loses recent legitimate content; not restoring far back enough just brings the same problem back.

Separate the files backup and database backup you'll need, and make sure they correspond to the same point in time. Mismatched versions, old files paired with a newer database or the reverse, are a common reason a restore only half works — the site loads but looks broken or references missing content.

Use phpMyAdmin's Import tab, select the backup file (a .sql or compressed .sql.gz), and keep in mind that importing overwrites existing tables — which is exactly why doing this on a staging copy first matters, so you can compare before committing on the live site. For sites with meaningful activity between the backup date and now, such as new orders or signups, consider whether that recent data can be recovered separately before overwriting it entirely.

Check that the database table prefix matches what the site's configuration file expects. A mismatch after restoring is a common cause of a site showing a blank page or a database connection error even though the import itself completed without a visible failure.