How to Restore WordPress from a Backup

Pick Your Restore Method (Decision Table)

Pick the method that matches the failure:

Before any method: if the site is broken but stable, restore to staging first and verify. If it is fully down, restore directly — speed beats ceremony. WebJi® customers can always ask the desk: host-assisted restores are part of the hosting, not an upsell.

Method 1: Plugin Restore (UpdraftPlus)

The self-serve path for a single broken component:

1. WordPress admin → UpdraftPlus → Backup / Restore tab.
2. Locate the backup set you want (existing backups) — check its date carefully.
3. Click Restore, then tick components: database alone fixes most plugin breaks; files+database for a full rollback.
4. Confirm through the prompts and wait — the log streams each step.
5. Clear caches (plugin and any CDN) and test the site logged-out.

Modifiers: if the dashboard itself is unreachable, reinstall the UpdraftPlus plugin from a fresh copy — its backups live outside WordPress core and survive reinstalls. Restoring to a staging copy first is the zero-risk variant when the site still loads.

Method 2: cPanel Full-Backup Restore

The account-level path, for hacked sites or full rebuilds:

1. cPanel → File Manager: confirm the scope of damage (a hack usually needs a full-account restore, not file-patching).
2. Request the host's snapshot restore, or upload your own cPanel-generated backup via Backup Wizard → Restore.
3. The restore replaces files, databases and email accounts to the snapshot moment — anything created after that moment is lost, so export recent orders/posts first if reachable.
4. After restore: rotate all passwords (cPanel, database, wp-admin), update WordPress core and plugins, and rescan for injected files.

A restore without credential rotation on a hacked site just re-arms the attacker. Security services handle the hardening pass if you would rather not.

Method 3: Manual Files Plus phpMyAdmin Import

Manual Files Plus phpMyAdmin Import. Allow 80 and 443 to the world, and restrict SSH (22) or RDP (3389) to known IPs. A site that times out after a firewall change is usually a closed web port, not a dead server. If you lock yourself out, use the console in the client area or email support@webji.services before you reboot in a loop.

Restore Gone Wrong: Common Errors

How this plays out with phpMyAdmin import: settings that look cosmetic usually decide page speed and uptime under real traffic. The defaults WebJi® ships are tuned for Indian network conditions, and support can review your setup on request.

Testing on Staging Before Going Live

Make the change on a staging copy, click through the homepage, a form and the checkout if you have one, then push it live. Staging is not a second production site — do not point the public domain at it. If the plan does not list staging, ask support@webji.services before you promise it to a client.

Host-Assisted Restores (WebJi®)

How this plays out with database import: settings that look cosmetic usually decide page speed and uptime under real traffic. The defaults WebJi® ships are tuned for Indian network conditions, and support can review your setup on request.