How to Fix Duplicator Backup Restore or Migration Failure

A Duplicator backup, restore, or migration usually fails because the server runs out of time, memory, disk space, file permissions, or database compatibility before the package can finish. The safest first action is to stop retrying the same failed package, download any available Duplicator log, and confirm you have a separate hosting backup before changing files or database settings.

Quick checks before changing anything

Start with the least risky checks. They tell you whether this is a Duplicator setting problem, a hosting limit, or a broken package.

1. Open Duplicator > Tools > Logs or the package details screen and download the latest log.
2. Check your hosting panel for disk usage. A backup can stall if there is not enough free space to build the archive and installer.
3. Confirm the package file is not 0B or unusually small. A restore package that never finished building should not be used for migration.
4. Temporarily pause caching, security scanning, and backup plugins that run heavy jobs at the same time.
5. If the failure happens during restore on a new host, compare PHP and database versions between the old and new servers.

Duplicator’s own troubleshooting documentation points readers toward logs, file permissions, large files, server timeouts, and plugin conflicts as common causes of backup failure: Duplicator backup troubleshooting.

Match the symptom to the likely cause

Symptom	Likely cause	First fix
Backup keeps running for hours	Timeout, low memory, huge file, blocked AJAX request, or exhausted disk space	Check Duplicator log, host resource usage, and exclude large non-WordPress folders
Archive is 0B	Package build did not complete	Do not restore it; rebuild after fixing storage or timeout limits
Restore fails on database import	MySQL/MariaDB version, SQL mode, charset, or packet-size issue	Check host database version and restore log before retrying
Warning appears only on Duplicator admin pages	Plugin warning, PHP compatibility warning, or conflict	Update Duplicator, WordPress, and PHP-compatible plugins; report repeat warnings to the vendor
Migration redirects or points to the wrong domain	Site URL replacement, cache, or old configuration left behind	Check WordPress URLs and clear host/plugin cache

WordPress stores the main site URLs in home and siteurl; if a migration loads the wrong domain after restore, confirm those values before editing unrelated files. WordPress documents these URL settings in its guide to changing the site URL.

Safest fix order

1. Save a backup outside Duplicator

Before repairing a failed migration, create or download a hosting-panel backup if your host offers one. If the original site is still online, also export the database and copy wp-content through your host’s file manager or SFTP.

This matters because a failed restore can leave the destination database partly imported. Retrying without a clean rollback point can make the next failure harder to diagnose.

2. Update Duplicator and clear old failed packages

In wp-admin, go to Plugins > Installed Plugins and update Duplicator if an update is available. Then go to Duplicator’s package list and remove failed or incomplete packages that you no longer need.

Do not delete a package until you have downloaded any log you need for support.

3. Check storage and exclude oversized files

A backup plugin has to create temporary files before the final archive is ready. If your site has large video files, old backup archives, cache folders, staging copies, or logs inside the WordPress directory, Duplicator may try to package them too.

In Duplicator, review the archive scan results and exclude obvious nonessential folders such as old backup directories, cache directories, and local staging exports. Keep wp-content/uploads unless you intentionally plan to migrate media another way.

After changing exclusions, build a fresh package. Do not reuse the failed archive.

4. Reduce timeout pressure

If the backup hangs or fails partway through, the web server may be ending the request before Duplicator finishes. This is common on shared hosting and large sites.

Try these in order:

1. Run the backup during low-traffic hours.
2. Exclude large backup/cache folders.
3. Ask the host whether PHP max_execution_time, memory limit, and web application firewall rules are interrupting long admin requests.
4. If your Duplicator edition supports alternate archive engines or build modes, use the option recommended by Duplicator for server timeout issues.

WordPress itself also depends on scheduled background tasks for some maintenance flows. If related jobs are not running reliably, review the official WordPress explanation of WP-Cron spawning before assuming Duplicator is the only failing component.

5. Check file permissions only after the log points there

Do not recursively loosen permissions across the site as a first fix. If the Duplicator log mentions write failures, check only the affected directory first.

For most WordPress installs, directories need to be writable by the web server where WordPress writes uploads, cache, and temporary plugin files. WordPress documents the general approach in its guide to changing file permissions.

If you use SFTP or a hosting file manager, check these areas:

• wp-content/uploads
• Duplicator’s backup/storage directory
• Any temporary directory named in the Duplicator log

Avoid setting broad 777 permissions unless your host specifically requires it for a temporary test, and revert it immediately afterward.

Restore and migration checks

A restore failure is riskier than a backup failure because the destination site may already be partly changed. Treat the destination as disposable until the restore succeeds.

Before restoring:

1. Create a fresh empty database for the destination when possible.
2. Confirm the destination database user has permission to create, drop, alter, and insert tables.
3. Upload a complete installer and archive pair from the same package.
4. Remove old installer files from earlier attempts.
5. Confirm the destination PHP and database versions are supported by your WordPress version.

Use Duplicator’s installer or import flow that matches your package and edition, and do not mix an installer from one package with an archive from another. If the installer opens but the import stops, download the installer log before deleting anything; it is the most useful clue for whether the failure happened during extraction, database import, or URL replacement.

WordPress lists current server recommendations on its hosting requirements page. If you are migrating from MySQL 5.7 to MySQL 8.0 or between different MariaDB/MySQL versions, treat database import errors as compatibility issues until the restore log proves otherwise.

Optional SSH checks

Use SSH only if you already have access and are comfortable with command-line recovery. These checks should not replace the Duplicator log; they help confirm the WordPress side of the destination.

Check whether WordPress can read its configured database:

wp db check

Check the active site URLs after restore:

wp option get home
wp option get siteurl

If the restored site points to the wrong domain, update the values only after confirming the correct destination URL:

wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'

WP-CLI documents these commands in its references for wp db check and wp option.

After the restore

Once the restore finishes, check the site from the outside, not only from the installer screen. Open the homepage, wp-admin, and one older post or product page. Confirm images load from the new domain and that Settings > General shows the correct WordPress Address and Site Address.

If front-end URLs return 404s after the migration, log in to wp-admin and save Settings > Permalinks once. WordPress documents this as part of permalink management in Using Permalinks.

Also check the latest PHP error log after repeating the action that used to fail. New Duplicator-related fatal errors are more useful than old entries from earlier failed attempts.

Rollback and escalation

If the original site is still working, leave it untouched until the destination migration is confirmed. If the destination restore is broken, wipe only the destination database and files, then restore from the hosting backup or start with a clean database before retrying.

Contact your host when the log points to server limits, blocked long-running requests, disk quotas, database permissions, or WAF/security rules. Contact Duplicator support when the package log shows a plugin warning, archive build bug, installer error, or repeat failure after storage, permissions, and server limits have been ruled out.

Send support the Duplicator log, the exact step where it failed, the package size, and whether the failure happens during backup creation, archive upload, installer startup, database import, or final URL replacement. That gives them the part of the migration that actually failed without exposing unrelated credentials or private server logs.