Trying to restore a backup of your site when the process suddenly stops with an HTTP 500 error can leave you unsure what to do next. The UpdraftPlus restore error 500 means your server encountered a problem while handling the restore request, but it does not necessarily mean that your backup is damaged.
Do not restart the restore just yet. This guide will help you protect your backup and current site, read the UpdraftPlus restore log, and find the last operation that completed successfully.
From there, you can narrow down the cause, whether it is a plugin conflict, resource limit, disk space, file permission, network, or hosting issue, and follow the safest route to recovery.
Stop repeating the restore. Save the backup and restore log, then identify the last completed step. Address the related cause, use Resume or Cleanup when available, and verify the site before attempting another restore or overwriting it.
What a 500 error means
HTTP 500 is a general server error. It tells you that the server could not finish the request, but not whether PHP, the server software WordPress uses, UpdraftPlus, the database that stores site content, the host, or a security filter caused it. A broader guide to WordPress HTTP 500 errors can help separate server symptoms from the UpdraftPlus restore step.
A restore can download backup files, unpack them, replace site files, update the database, and run for much longer than a normal dashboard action. The site may work before the restore and still fail during it. The backup may be valid while the server cannot finish the job.
Protect the site before retrying
Repeated full restores can replace more files or database records. That can turn one clear failure into a mixed site state that is harder to recover.
- Preserve every backup component and the current site: Keep the database, plugins, themes, uploads, and other files in a separate safe location. If needed, make a manual WordPress backup before testing again. Do not delete the only copy stored on the server.
- Record the failed attempt while the details are fresh: Note the backup date, failure time, selected components, last visible message, and recent WordPress, PHP, plugin, theme, or hosting changes.
- Use the recovery control that UpdraftPlus offers: Choose Resume when it identifies an interrupted restore. Use Cleanup or Delete old folders only after confirming that the original backup is safe elsewhere.
- Choose staging for risky tests: A WordPress staging site is a private copy used for testing. Use one when possible because a restore can replace the components selected on the restore screen.
In a hands-on test with UpdraftPlus 1.26.6, the restore screen warned that selected components could replace site content. It allowed the database, plugins, themes, uploads, and other files to be selected separately. That warning is a reason to control the next restore, not to start another full overwrite immediately.
Read the restore and server logs
UpdraftPlus normally stores backup and restore logs in wp-content/updraft. Their names begin with log. The Backup / Restore screen may also show Download and View Log. Open the file whose timestamp matches the failed attempt.
Start at the end of the log. Find the last operation before the error, such as a database action, uploads archive, remote download, file write, permission check, or updraft_send_command. That clue tells you which fix to test.
- Enable private error logging for one test: Turn on WP_DEBUG and WP_DEBUG_LOG, which record WordPress and PHP errors, while keeping WP_DEBUG_DISPLAY set to false so errors are not shown to visitors. Add the settings before the “That’s all, stop editing!” line in
wp-config.php, then remove them after collecting the evidence:define( ‘WP_DEBUG’, true );
define( ‘WP_DEBUG_LOG’, true );
define( ‘WP_DEBUG_DISPLAY’, false );
The WordPress debugging guide shows the settings. - Request host records for the same minute: Ask for PHP, PHP-FPM, web-server, account-resource, and database errors. PHP-FPM is the service that runs PHP requests on many hosts.
- Check the security and traffic layers: Ask whether ModSecurity or another web application firewall blocked the request. Also ask whether a proxy, which sits between visitors and the server, timed out first.
- Remove temporary debugging after collection: Protect or delete the logs after saving the needed evidence because they may contain file paths, usernames, or database details.
Match the failed phase
| Last operation or symptom | Check next |
|---|---|
| The request fails before the restore starts or returns broken page content | Other plugins, security rules, the web application firewall, the proxy, and host logs |
| A database action or updraft_send_command fails | Plugin conflicts, PHP errors, database access, and compatibility |
| A remote backup will not download | Missing backup parts, remote storage access, disk space, and host connectivity |
| An uploads archive or other large file fails | Free space, archive size, time limits, and separate component restores |
| A file or folder cannot be read or written | Ownership, permissions, writable paths, and hosting quota |
| The restore appears complete but the site is broken | Partial restore state, matching files and database, PHP errors, and site checks |
Change one relevant thing at a time. If you disable plugins, raise a limit, and change server rules together, the next attempt cannot show which change helped.
Apply the evidence-based fix
Isolate database and plugin conflicts
The database holds posts, settings, users, and other structured site data. If the log names a database step or updraft_send_command, test the smallest suspected plugin group before importing the database again.
- Deactivate only the suspected plugins for one controlled test: Use wp-admin, the WordPress dashboard, if it works. Otherwise, rename only the suspected plugin folder with SFTP, a secure way to manage server files, and record its original name for rollback.
- Restore protection after the test: Re-enable plugins one at a time. Do not leave security or backup protection disabled on a live site.
- Treat compatibility as a confirmed exception: A database character setting such as utf8mb4 may need host review, but a database 500 alone does not prove that it caused the failure.
Check memory and time limits
Memory and time are separate limits. A large restore can exceed PHP memory, the maximum script time, a PHP-FPM process limit, a web-server timeout, a proxy timeout, or an account CPU limit. If the log shows memory exhaustion, compare it with this guide to fatal memory errors in WordPress. Raising one setting will not help if another limit stops the request.
TeamUpdraft’s current restoration guidance recommends at least 512M of memory and 900 seconds of execution time for some environments. These are recommendations, not guarantees. For the time-limit symptom, see how to fix maximum execution time errors in WordPress, then ask the host to confirm the limits that actually apply to your account.
Check space, downloads, and large files
UpdraftPlus needs temporary storage while it downloads, unpacks, and moves backup parts. Check available disk space, the hosting quota, and the file-count limit, sometimes called the inode limit. TeamUpdraft recommends at least 50% free space before some restorations.
- Protect the original before cleanup: Use Cleanup or Delete old folders when UpdraftPlus identifies leftovers. Do not manually remove an archive or folder that may still be part of the current recovery.
- Confirm remote files before blaming the backup: If a download fails, check that every selected backup part exists in remote storage, the host permits the connection, and there is enough local space to finish it.
- Restore large parts in a controlled order: The uploads part often contains large images and videos. Restoring components separately can reduce timeout risk, but document the order and leave the database until last when the restore guidance calls for it.
- Escalate very large sites early: Ask the host or UpdraftPlus support whether a supported WP-CLI restore is available. WP-CLI runs WordPress tasks from the command line instead of through a browser request.
Check security rules and server permissions
A plugin, theme, firewall, or security module can stop the restore or block its request. This is more likely when the log shows updraft_send_command, broken page content, or a security event.
- Run one narrow conflict test: Disable only the smallest suspected set. If ModSecurity or another web application firewall blocked the request, ask the host to review the matching event or temporarily bypass that rule for the restore.
- Ask the host to correct ownership: The restore needs to read backup files and write to temporary and destination folders. See this guide to WordPress file permissions before changing access. 755 for folders and 644 for files are common starting points, not universal commands to apply recursively.
- Back up server rules before testing: If the log points to .htaccess, a file containing Apache web-server rules, copy it before temporarily renaming it. Restore the original if the test does not explain the error.
Retry and verify the result
After the logs point to a likely cause, test the smallest change that can confirm it.
- Resume the interrupted restore when available: Use Resume instead of starting a second full restore. Use Cleanup first if UpdraftPlus reports old restore folders and the complete backup exists elsewhere.
- Restore only the needed component: Avoid a full overwrite when a smaller component can test the fix.
- Watch both logs during the attempt: Stop if a new error appears. Do not keep refreshing a request that may still be changing site data.
- Confirm every selected component finished: A browser success message does not prove that the files, database, uploads, and other selected parts all completed.
- Test the recovered site beyond the dashboard: Check the public pages, login, links, media, forms or checkout, scheduled tasks, and important integrations. Create a new backup only after the site and data are correct.
On August 19, 2026, we installed UpdraftPlus 1.26.6 on WordPress 6.9.4 with PHP 8.3 and MySQL 8.0. A local database-and-files backup completed at 07:12:15. A database-only restore then displayed Restore successful! and recorded table replacement using a temporary r3_ prefix, which is a temporary table name used during the change. The test confirmed the normal controls and a successful restore path. It did not reproduce an HTTP 500, so it cannot identify the cause of every live-site failure.
Recover without wp-admin
If the WordPress dashboard is unavailable, use the host’s file manager or SFTP to preserve the backup and collect evidence. Give support the backup time, selected component, exact UpdraftPlus message, WordPress and PHP versions, recent changes, and tests already completed.
Ask the host for PHP-FPM and web-server errors, CPU and process limits, disk and file-count usage, firewall events, and database errors from the failure time. If the site may be partly restored, do not import another database or delete restore folders until someone confirms its state.
Manual recovery is possible because UpdraftPlus components are standard ZIP archives and SQL files, which contain the site files and database instructions. It is not a quick browser fix. If you need a broader restore WordPress from a backup workflow, start with a fresh or staging WordPress installation, confirm that every archive and database file is present, set the correct database details, and keep a recoverable copy before importing anything.
Contact UpdraftPlus support, the host, or a WordPress professional if the database is mixed, the backup is incomplete, or you cannot tell whether the current site is safe to overwrite.
Prevent another failed restore
- Keep complete backups away from the host: Store copies somewhere you can access if the WordPress server goes down.
- Test recovery before an emergency: A successful backup job does not prove that the live server can restore it. Review common WordPress backup failures and use staging for restore tests.
- Maintain space and resource headroom: Check free disk space and account limits before restoring a large uploads archive.
- Update software in a controlled order: Update WordPress, PHP, UpdraftPlus, themes, and other plugins with a fresh backup before risky changes.
- Review unused software and security rules: Old plugins and strict request filters can interfere with long-running restore actions.
- Keep a recovery record: Save the restore date, selected components, order, logs, and final site checks with the backup.
BlogVault is one backup-plugin option to evaluate if you want recovery separated from the WordPress request. Its current product information describes a backup and restore workflow with independent storage, restore testing, emergency recovery when wp-admin is unavailable, and selective or differential restores.
You can also compare the broader WordPress backup plugin options before choosing a recovery plan. Those features support future recovery planning, but they are not a guaranteed cure for an existing UpdraftPlus 500 error.
Conclusion
An UpdraftPlus restore error 500 is a signal to stop guessing. Preserve the backup, find the last completed operation, and let the matching UpdraftPlus and server evidence choose the next fix.
Retry only after you understand the partial state. Use Resume or Cleanup when appropriate, verify the site beyond the dashboard, and involve the host or a recovery professional before overwriting a site that may be only partly restored. For the normal recovery sequence, follow an UpdraftPlus backup and restore guide.
FAQs
Why does UpdraftPlus show a 500 error during a restore?
A 500 is a general server response, not a diagnosis. The cause may be a PHP error, memory or time limit, low disk space, a plugin or security conflict, a permission problem, a failed remote download, a proxy timeout, or database compatibility. The restore and server logs identify the relevant cause.
Where does UpdraftPlus save restore logs?
UpdraftPlus normally saves them in wp-content/updraft, in files whose names begin with log. The Backup / Restore screen may also provide Download and View Log. Match the timestamp to the failed attempt.
Can I retry after a failed UpdraftPlus restore?
Yes, but first preserve the backup and current site, inspect the logs, and use Resume or Cleanup if UpdraftPlus offers it. If a new attempt is needed, restore the smallest component that tests the suspected fix instead of starting with a full overwrite.
Will increasing PHP memory fix the error?
It can help when the logs show memory exhaustion, but it is not a universal fix. The host, PHP-FPM service, web server, proxy, or account limit may still stop the request. Ask the host to confirm the effective limits before changing WordPress settings.
What should I do if wp-admin is unavailable after the error?
Protect the backup, collect the UpdraftPlus and host logs, and ask the hosting provider to check server errors, resource limits, disk space, permissions, security rules, and database state. Use a fresh or staging WordPress installation for manual recovery, and get expert help before overwriting a site that may be partly restored.
Shivani enjoys crafting guides that make every aspect of using WordPress simple and easy to follow. When she's not glued to her laptop, you can find her buried in a good book or occasionally, painting.
