If WPvivid's restore process is stuck at a percentage that never moves, stuck on "Please wait, do not close this window," or has failed with an error partway through, this is almost always one of four specific causes: a PHP resource limit that's too low for the restore, a backup zip file that didn't download or transfer completely, insufficient disk space on the server, or a database connection method the restore can't use. Work through the diagnostic order below rather than guessing — it'll tell you which cause you're actually dealing with in a few minutes.

Symptoms

  • The restore progress bar stops at the same percentage every time you try (often during the database import or file extraction stage).
  • WPvivid shows a timeout error, a "500 Internal Server Error," or the page simply goes blank mid-restore.
  • The restore appears to finish, but the site is broken, missing content, or reverts to its pre-restore state.
  • An error message references memory, execution time, disk space, or a database connection failure.

Likely causes, in order of how often they actually happen

  1. PHP memory_limit or max_execution_time is too low. A restore has to decompress a zip file, write potentially thousands of files, and import a full database dump. On shared hosting with default PHP limits (often 128M memory and 30–60 seconds execution time), a restore for a site with any real amount of content or media routinely exceeds both.
  2. The backup zip is corrupted or incomplete. If the original backup was interrupted, or the file was uploaded/transferred to the server (from cloud storage or a manual upload) and didn't complete fully, WPvivid will fail partway through trying to extract or read it — sometimes with a generic error rather than an obvious "corrupt file" message.
  3. Insufficient disk space on the destination server. A restore needs enough free space for the compressed zip, the fully extracted files, and (temporarily) the old site files it's replacing — meaning the actual space required during a restore can briefly be 2–3x the backup's zip size. Many hosting accounts are close to their disk quota and don't have this headroom.
  4. Database connection method mismatch. WPvivid can import the database either through a direct MySQL connection or, on hosts that restrict this, through alternate PHP-based methods. If the site was moved between hosts with different database access permissions, or the destination host blocks the connection method WPvivid defaults to, the database import stage fails specifically.

Fix it: lowest-risk steps first

Step 1 — Confirm the backup zip itself isn't corrupted

Before changing any server settings, rule out a bad backup file.

  1. In WPvivid, go to All Backups and download the backup archive to your own computer (or locate it in your cloud storage destination if you're using remote storage).
  2. Try opening the zip with a standard archive tool (Windows Explorer, 7-Zip, or macOS Archive Utility). If it throws an "archive is corrupt" or "unexpected end of archive" error, the file itself is the problem — not your server.
  3. If the zip won't open cleanly, go back to the original backup task in WPvivid and run a fresh backup rather than continuing to retry the restore with a damaged file. If the site that produced the backup is still available, this is the fastest fix.
  4. If you're restoring a zip that was uploaded manually to the server, re-upload it via FTP in binary mode (not ASCII) and confirm the file size on the server matches the original exactly.

Step 2 — Check available disk space on the destination server

In your hosting control panel (cPanel, aaPanel, Plesk, or your host's dashboard), find disk usage/quota — usually under "Disk Usage" or "Statistics."

  • Confirm you have free space at least 2–3x the size of the backup zip you're restoring. If you're near your quota, delete old backup files, unused media, or log files first, or temporarily upgrade your hosting plan's storage if that's not possible.
  • If your host doesn't show this clearly, ask their support directly — "how much free disk space does this account have" is a fast support ticket to resolve.

Step 3 — Raise PHP memory_limit and max_execution_time temporarily

This is a low-risk, reversible change — you're only raising the ceiling, not changing default behavior.

  1. If you have access to wp-config.php, add (or edit) define('WP_MEMORY_LIMIT', '512M'); near the top, before the line that says "That's all, stop editing!"
  2. If you can edit php.ini or have an "Additional PHP configuration" option in your hosting panel (common in cPanel's MultiPHP INI Editor or aaPanel's PHP settings), set memory_limit = 512M and max_execution_time = 300 (or higher for very large sites).
  3. If you don't have panel access, ask your host to raise these two values temporarily for the restore — most hosts will do this on request even on shared plans.
  4. Retry the restore after applying these changes. Most restores that stall or time out on large sites succeed once these two limits are raised.

Step 4 — Switch the database connection/import method

If the restore consistently fails specifically at the database import stage (not file extraction), this points to cause #4.

  1. In WPvivid's restore settings, check whether an alternate database import method is offered (WPvivid documents this in its restore troubleshooting guidance — the option name may vary by plugin version).
  2. If your host restricts direct database connections from PHP (some managed hosts do this for security), contact them to confirm whether the database user WPvivid is using has the necessary privileges, or whether a different connection approach is required on their platform.
  3. As a fallback, you can import the database manually: extract the .sql file from the backup zip and import it directly through phpMyAdmin or your host's database tool, then let WPvivid (or a manual file copy) handle just the file restoration separately.

Verify the fix

  1. The restore progress bar completes to 100% without stalling or throwing an error.
  2. The site loads normally in a browser, and spot-check a few pages, the media library, and the admin dashboard.
  3. Confirm the database restored correctly by checking that recent posts, settings, and any custom content from the backup's timeframe are present.

If you need to roll back

If a restore partially completes and leaves the site in a broken or mixed state, restore the "before" backup you took in the warning step above — this returns the site to exactly where it was before you started troubleshooting. If you don't have that backup, and the site is currently unreachable, check whether your host keeps automatic server-level backups (many hosts snapshot nightly) as a last resort before rebuilding from scratch.

Related fixes

FAQ

Why does the restore work fine on a staging site but fail on my live server?

This usually points to a difference in PHP resource limits or disk space between the two environments — staging environments (especially local or managed staging tools) often have more generous default memory and execution time limits than production shared hosting. Compare the PHP settings on both if you can, via phpinfo() or your hosting panel.

Should I split the backup into smaller pieces if the file is very large?

WPvivid already splits backups into multiple parts automatically once they exceed a size threshold, so this isn't something you typically need to configure manually. If a restore is failing on a very large site, raising PHP limits (Step 3) and confirming disk space (Step 2) address the underlying cause more directly than trying to change how the backup is packaged.

Is it safe to just keep clicking retry on a stuck restore?

Retrying without changing anything rarely helps, since the same resource limit or corrupted file will cause the same failure again. Worse, repeatedly interrupting a restore partway through can leave the site's files or database in a partially-overwritten state, which is why taking a fresh backup before you start troubleshooting (per the warning above) matters — it gives you a clean point to return to.