How to Restore a WordPress Backup: Pick the Right Route Before You Overwrite Anything

This post contains affiliate links. If you buy something through one of them, Veravix may earn a commission at no extra cost to you.

An update goes wrong, the site shows a critical error, and your host’s dashboard has a Restore button sitting right there. Most people click it. The part that catches them is on the confirmation screen: restoring overwrites what is there now, and Hostinger’s own documentation says plainly that it cannot be undone.

A restore is a decision about which half of your site to rewind, and how much of the recent past you are willing to lose. I read the WordPress developer documentation, Hostinger’s backup page, phpMyAdmin’s FAQ, the WP-CLI command references, and the WordPress and WooCommerce source code on 13 October 2026. This guide covers the four restore routes, what each one overwrites, and the checks to run afterwards. If the break started after a PHP change, How to Check Your WordPress PHP Version (and Whether It Is Time to Upgrade) helps you find the cause, because restoring hides a PHP mismatch without removing it.

Which restore route fits your situation

Pick the route from what still works, not from what sounds easiest.

What you have	Route	What it overwrites
The dashboard and the front end are both dead, and your host keeps backups	Host panel restore	Files only, database only, or both, depending on what you choose
wp-admin still loads, and a backup plugin ran before the break	Plugin restore	Only the components you tick, such as plugins, themes, uploads or the database
No host backup, or a backup you downloaded yourself	Manual restore with FTP and phpMyAdmin	Every file you upload over, and every table in the imported dump
SSH access and a large database	WP-CLI import	The tables in the dump you import

The plugin route has one hard requirement: the plugin itself has to run, which means wp-admin has to load. When the site is down at the PHP level, you are already in host-panel or manual territory.

A backup is two halves, and they have to come from the same moment

WordPress’s own developer guide states it directly: a full backup is the database plus the files, and you need both to restore a typical site. The files are the WordPress directory, including core, themes, plugins, uploads, wp-config.php and .htaccess. The database holds the posts, comments, settings and users, and it lives in a separate MySQL or MariaDB system, so copying the folder never captures it.

The guide also gives an order: restore the files first, then import the database, and update wp-config.php if the database credentials changed.

The reason they must match is that the database remembers things about the files. It records which plugins are active, which theme is in use and which settings each plugin saved. Put last Friday’s database under last Tuesday’s plugin files and you can end up with a plugin that expects settings its older code never wrote. This is also why a “database only” restore is the riskiest button on the screen.

To see what a database restore rewinds, I counted the tables in the source code on 13 October 2026.

Source	Tables created	What lives there
WordPress core, single site	12	Posts, post meta, comments, comment meta, terms, term meta, term taxonomy, term relationships, links, options, users, user meta
WordPress core, multisite extras	6 more	Blogs, blog meta, registration log, site, site meta, signups
WooCommerce installer	29 from plain CREATE statements	Sessions, API keys, tax rates, shipping zones, payment tokens, webhooks, stock reservations, analytics lookups, and more

WooCommerce adds more when they apply, including the high-performance order storage tables, the product attribute lookup and stock notification tables. A store’s orders, customers, tax setup and shipping zones sit in that database, so a database restore on a store takes them all back to the backup’s date. Any order placed after the backup is missing from the site, although your payment provider still has it. That is the number to check before you restore a live store. How to Optimize a WooCommerce Database: Sessions, Action Scheduler, and Orders explains which of those tables are working data and which are only housekeeping.

Save the broken site before you overwrite it

A restore can fail halfway, and a backup can turn out to hold the same fault you are trying to remove. Keeping a copy of the current state turns both into small problems.

• Download the files over FTP or the host’s file manager, even if you only need the wp-content folder and wp-config.php.
• Export the database from phpMyAdmin. A broken-looking site often still has an intact database, and that database holds the orders and comments written since the backup.
• Write down the restore point you picked, so you can try the next older one if the first has the same fault.

Restoring from the host panel

This is the route to use when the site cannot load at all. On Hostinger, the steps are in the hPanel Backups section: find the backup you want, click Restore, choose Files only, Database only or Full backup, and confirm. The documentation warns that restoring overwrites your current files and database and that the action cannot be undone.

Several details from Hostinger’s backup page affect how much you can rely on it:

• Backups run weekly by default. Daily backups come with plans that include them, and a weekly plan can add a Daily backups add-on.
• Manual backups can be created once every 24 hours, and entry-level plans need a Business plan or higher to create them.
• A backup covers everything in public_html and its subfolders, plus the MySQL databases. Email mailboxes and server configuration are not included.
• The page does not say how long backups are kept or how many are stored. If you need a specific date, open the list and check what is there before you plan around it.

On a weekly plan, the newest backup can be six days old. For a blog that is a few lost drafts. For a store it is six days of orders. Choose Full backup unless you know which half is damaged, because mixing a new database with old files, or the reverse, is the mismatch described above.

Restoring with a backup plugin

A plugin such as UpdraftPlus lets you choose what to bring back instead of replacing everything. If only a bad plugin update caused the break, restoring just the plugins component leaves your posts and orders alone. That is a real advantage over a host panel’s all-or-nothing choices on a store.

The domain is the part to watch. A backup taken on one address and restored on another keeps the old address inside the database. UpdraftPlus’s support replies describe ticking the option to search and replace the site location during the restore, and the Advanced Tools tab has a Search/Replace Database tool for fixing it afterwards. The same reply warns that this is a full database operation that you cannot reverse, so take the database export first.

Restoring by hand with FTP and phpMyAdmin

This route works when nothing else does, and it follows the order in WordPress’s own guide.

1. Upload the backed-up files to the site root, including wp-content. Keep the current wp-config.php if its database details are still correct.
2. Open phpMyAdmin, select the site’s database and use the Import tab to load the .sql file. If you are moving to a new database, create it first and put its name, user and password in wp-config.php.
3. Load the site and check the front page, wp-admin and one inner page.

The step that fails most often is the import itself, and phpMyAdmin’s FAQ names the cause. Four PHP settings limit what phpMyAdmin can accept: upload_max_filesize, post_max_size, memory_limit and max_execution_time. The post_max_size value must be larger than upload_max_filesize. When you cannot raise them, the FAQ gives three ways around the limit: put the file in an upload directory and import from there, split the dump with a tool such as BigDump, or import from the command line.

With SSH access, the command-line route is short. wp db import backup.sql reads the database details from wp-config.php and runs the file against the database. The WP-CLI documentation notes that the command does not create the database, so it must already exist.

After the restore: three checks

Check the site address. WordPress stores two addresses in the database, the WordPress Address and the Site Address. Both need the full https:// and no trailing slash. If you restored onto a different domain, a plain find and replace across the database can corrupt serialized settings, because those values record their own string lengths. WP-CLI’s search-replace command handles serialized data and has a --dry-run flag that shows the changes without saving them. Its documented domain-change example skips the guid column, and the WordPress guide says never to change guid values at all.

Rebuild the WooCommerce lookup tables. Several WooCommerce tables are indexes built from your products and orders, such as the product lookup table. After a restore, open WooCommerce, Status, Tools and run the lookup table regeneration. Support threads also suggest clearing the analytics cache and re-importing historical data if the Analytics screens look wrong, so test those on a copy first. For the wider database picture, WordPress Database Optimization: The Autoloaded-Data Problem Most Guides Skip shows what else sits in the options table you just restored.

Make sure the backup was not already broken. If the same error returns, the backup was taken after the fault began. Try the next older restore point, and keep the export of the broken site until the restored one has run for a day.

Checked for accuracy on 13 October 2026 against the WordPress developer guide on backups, its guide to moving a site, Hostinger’s backup documentation, phpMyAdmin’s FAQ, the WP-CLI references for db import and search-replace, and the WordPress and WooCommerce source code.