Restoring a WordPress backup from cPanel can bring back a site affected by a failed update, server problem, hacking incident, or configuration mistake. The process is safest when you restore the matching website files and database together. Using the wrong versions can lead to missing images, login problems, broken links, lost orders, or additional data loss.
This guide covers the recovery process from start to finish: finding the correct WordPress installation, identifying its database, preserving the current site, restoring files and database data, updating wp-config.php, and testing the result.
If the site is currently showing a 500 error or a blank white screen, record any recent changes before you begin. These related guides may also help: how to fix WordPress 500 internal server errors and how to fix the WordPress White Screen of Death.
What a WordPress backup contains
A complete WordPress backup normally has two separate parts:
- Website files: WordPress core files, themes, plugins, uploaded media, and configuration files.
- Database: Posts, pages, users, settings, WooCommerce products and orders, and data created by plugins.
These two parts should come from the same backup date whenever possible. Restoring files from one date and a database from another can cause plugin conflicts, missing media, incompatible settings, or lost content.
Common file backups use formats such as .zip, .tar.gz, or .gz. Database exports are often provided as .sql or .sql.gz files. Depending on the host, you may receive a full-account backup or separate backups for the home directory and database.
Step 1: Identify the correct WordPress files and database
Find the site’s document root
Log in to cPanel and open File Manager. Common WordPress locations include public_html, a folder assigned to an addon domain, or a subdirectory used by the site.
The WordPress root normally contains:
wp-adminwp-includeswp-contentwp-config.php
Do not assume that public_html is always the correct location. Open Domains in cPanel and check the domain’s document root before uploading or extracting anything.
Match the database to the files
Open the current wp-config.php file and note these values:
DB_NAMEDB_USERDB_HOST$table_prefix
The database backup should belong to that site and use the same table prefix. For example, tables beginning with wp9x_ show that the site uses a custom prefix instead of the default wp_.
Compare the backup dates and file sizes. On a WooCommerce site, choose a backup that includes the orders and customer records you need to recover. If the backup contents or date are unclear, ask the hosting provider or a WordPress developer before changing the live site.
Step 2: Create a safe recovery copy
Do not delete the only copy of a damaged site. Before restoring anything, preserve the current files and database—even if the site is not working. That copy may contain recent uploads, orders, or configuration changes that are not present in the older backup.
Back up the current files
In File Manager, select the WordPress directory, click Compress, and create an archive outside the public web directory if your hosting setup allows it. Use a clear name such as site-before-restore-2025-03-08.zip. Download the archive or move it to secure storage.
Export the current database
Open phpMyAdmin, select the database named in wp-config.php, and choose Export. The quick export option with SQL format is usually suitable unless your host recommends another method.
Handle these copies as sensitive data. Database exports can contain usernames, email addresses, order details, and other private information. Do not leave temporary exports in a publicly accessible folder.
Step 3: Restore the WordPress files in cPanel
If possible, put the site into maintenance mode while the restore is in progress. If the dashboard is unavailable, restrict access through your hosting tools or work during a low-traffic period.
Open the correct document root in File Manager. Instead of deleting the existing files immediately, rename the directory or move its contents into a dated recovery folder, such as public_html-before-restore. Confirm that the folder is not still being used as the active document root.
Upload the matching backup archive, select it, and click Extract. Check the extracted structure before continuing. A common mistake is creating a nested path such as public_html/backup/wordpress/wp-content when the domain actually expects public_html/wp-content.
If the archive creates a top-level folder, move the contents of that folder into the real document root. Keep wp-content together because it contains themes, plugins, uploads, and sometimes custom files required by the site.
Step 4: Create or prepare the destination database
Open MySQL Databases in cPanel. You can reuse the existing database after exporting it and replacing its tables, or create a new database for the restored site. A separate destination database is generally easier to reverse because the original database remains available during testing.
If you create a new database, create a MySQL user and grant that user All Privileges on the database. Record the exact database name, username, password, and host. Shared hosting often uses localhost as DB_HOST, but follow the value supplied by your host if it differs.
In phpMyAdmin, select the destination database, click Import, and upload the matching .sql file. For a compressed export, use the format supported by your host. Large imports may exceed upload or execution limits. If that happens, ask the host to import the file or use a command-line method if SSH access is available.
Step 5: Update wp-config.php
Edit the restored wp-config.php so its database settings match the destination database:
define( 'DB_NAME', 'cpanel_database_name' );
define( 'DB_USER', 'cpanel_database_user' );
define( 'DB_PASSWORD', 'your-database-password' );
define( 'DB_HOST', 'localhost' );Also check that $table_prefix matches the tables imported into phpMyAdmin. Do not replace the WordPress security keys unless you have a specific reason. Replacing them logs out active users, which may be undesirable during a live-site recovery.
Review the file for temporary settings, including debugging options that should not remain enabled on a public production site. If you moved the site to another domain or staging URL, the database URLs may need to be updated as well. Use a WordPress-aware search-and-replace tool rather than a basic SQL replacement, since careless edits can damage serialized theme and plugin data.
Step 6: Test the restored website
Open the homepage in a private browser window and work through the site as a visitor and administrator. Check:
- WordPress login and administrator access
- Pages, posts, categories, menus, and internal links
- Images, uploaded files, and the media library
- Plugin and theme settings
- Contact forms, email notifications, and SMTP delivery
- WooCommerce products, cart, checkout, payment settings, and order history
- HTTPS, redirects, robots.txt, and canonical URLs
Visit Settings > Permalinks and click Save Changes once to refresh the rewrite rules. If the site fails, avoid making several changes at once. Temporarily enable logging where appropriate and review the PHP and server error logs. For PHP compatibility issues, see how to change the PHP version for WordPress in cPanel safely.
When the main checks pass, remove maintenance mode, clear approved page and object caches, and monitor the site. Keep the pre-restore files and database until you have confirmed that important content, customer records, and transactions are present.
When to involve a WordPress developer
A straightforward backup may be restorable through cPanel, but professional assistance is sensible when the backup is incomplete, the database is large, the site has been hacked, or WooCommerce data changed after the backup date. Repeated trial-and-error changes can make later recovery more difficult.
Recovery work may include the cPanel restore itself, database troubleshooting, plugin conflict investigation, PHP compatibility checks, WooCommerce testing, and a post-recovery security review. If the site handles payments or customer data, have the recovery plan reviewed before making production changes.
Frequently asked questions
Can I restore only wp-content?
Yes, if the WordPress core and database are still healthy and you only need to recover themes, plugins, or uploads. Copying files alone will not restore posts, pages, users, or settings stored in the database.
Should I delete the old database before importing?
Not immediately. Export it first and use a separate destination database when possible. If you must reuse the existing database, make sure the backup is complete and that the old tables are replaced carefully.
Why does the restored site show “Error establishing a database connection”?
The database name, username, password, host, or user privileges in wp-config.php are usually incorrect. Compare each value with the settings in cPanel and confirm that the user has privileges on the selected database.
Why are images missing after restoration?
The database may have been restored without the matching wp-content/uploads directory, or the files may have been extracted into a nested folder. Check the upload path and confirm that the web server can read the files.
Conclusion
A careful cPanel restoration follows a simple order: identify matching files and database data, preserve the current site, restore into the correct locations, update the database credentials, and test the important functions. For a business-critical site, especially one handling payments or customer information, controlled recovery is safer than deleting files and hoping the backup works.