WordPress files can restore successfully while wp-config.php points to an old, empty or unrelated database. The site may show the installer, old content or an “Error establishing a database connection” even though uploads and plugins look current.
Do not run the installer. It can create fresh tables in the wrong database and make recovery harder to interpret.
Preserve the current state
Take a cPanel backup/snapshot of files and every candidate database before importing again. Record restoration time, backup filename, source and errors.
Disable new writes or use maintenance mode while the correct dataset is determined.
Do not overwrite the only pre-incident backup.
Read WordPress configuration safely
Inspect DB_NAME, DB_USER, DB_HOST and $table_prefix without exposing passwords.
define( 'DB_NAME', 'example_database' );
$table_prefix = 'wp_';Check for duplicate/environment overrides and confirm the active document root. Restored files from another site may contain its configuration.
Rotate any credentials exposed during diagnosis.
Inventory cPanel databases
List database names, sizes, users and privileges. In phpMyAdmin, inspect table prefixes and latest post/user timestamps with read-only queries.
SELECT ID, post_date, post_title
FROM wp_posts
WHERE post_type IN ('post','page')
ORDER BY ID DESC
LIMIT 10;Use actual prefix and avoid publishing private titles.
Match backup timestamps
The files backup and SQL dump may be created at different times. Compare uploads modification dates, plugin versions and latest database content.
Identify which SQL dump belongs to the site using siteurl/home, table prefix and content, not filename alone.
Do not assume the largest database is correct; logs/cache tables can dominate size.
Recreate user grants
cPanel restores may import a database without attaching the WordPress user. Use MySQL Databases to create/assign a least-privileged user to the intended database.
Avoid global privileges. Test the credential from the WordPress hosting context without putting the password in shell history.
Keep the old user until the corrected configuration is verified, then revoke unused access.
Import into a separate target
Rehearse by creating a new database and importing the selected dump there through cPanel restore or MySQL client. Capture exit/errors and compare table/row counts.
Do not import repeatedly into a partially populated target; duplicate keys/mixed dates result.
Check charset/collation and large-file limits before production cutover.
Switch atomically
Update wp-config.php database name/user/password together, preserving syntax/permissions. Clear persistent object cache so old options do not appear.
Do not change WordPress URLs until confirming the database belongs to this domain. Then use precise/serialisation-aware tools for migration values.
Keep rollback configuration outside the public root.
Reconcile data newer than the backup
List content, users, comments, submissions and operational records created after the chosen SQL dump. Compare stable IDs/timestamps with the pre-repair/current databases.
Do not copy arbitrary rows across databases; numeric IDs and related metadata can collide. Use application-aware exports/APIs or a rehearsed merge on staging. Pair attachment records with their original files and prevent new writes during the final merge window.
External email/payment effects cannot be recreated safely from database rows alone; reconcile them with their own provider references.
Inspect serialised and environment-specific options
A dump from staging or another path may contain serialised builder/widgets, cache prefixes, cron events and absolute URLs. Use WP-CLI search-replace dry runs and plugin-supported migration tools.
Do not copy wp_options wholesale from another database after selecting the correct content. Review siteurl, home, active plugins/theme, roles, cron and integration endpoints individually. Clear persistent object cache only after the database/config switch.
Verify restored data
Test public content, login, editor/save, media, plugins, cron and newest records. Compare counts/timestamps with the chosen backup.
Inspect external email/payment/submission systems for events after the backup that require reconciliation. Recurring care should label backups with site/database/time and rehearse paired restores; files alone are not a WordPress recovery.