Troubleshooting
Fix Restore White Screen
Diagnose and resolve restore white screen during WordPress Multisite backup or restore with Multisite Migrate.
Free
Fix: Fix Restore White Screen
When you hit restore white screen, start with the Multisite Migrate job log: last completed chunk, PHP/memory messages, HTTP 502/504, disk/inode errors, or cloud auth failures. Multisite archives are larger and table-heavier than single-site jobs, so shared hosts interrupt long PHP requests — Jobs in Chunks exist specifically for that.
Check tmp/disk free space, upload_max_filesize for imports, S3/Drive/Dropbox/SFTP credentials for Plus uploads, and security plugins that block admin-ajax. After restore issues, verify siteurl/home, rewrite rules, domain mapping (sunrise.php), object-cache drop-ins, and CDN caches. Reproduce once on Staging before changing production limits.
Log-first diagnosis for “Restore White Screen”
Separate backup failures from post-restore URL/media/login problems. Capture job percent, last log line, HTTP status, hosting class, and whether a local archive already exists. That evidence decides whether you raise PHP limits, free disk, fix cloud auth, or only re-upload.
For “restore white screen”, avoid restarting from scratch if a chunked job can resume. Lost locks, cleared tmp, or a new job ID are common reasons a progress bar jumps back to 0%.
Fixes that match Multisite reality
Raise PHP time/memory enough for safety, but keep chunked jobs — shared hosts can still kill long workers. Free disk and inodes before large network archives. Allow admin-ajax through WAF or security plugins. On Plus, re-test Drive/Dropbox/S3-compatible/SFTP credentials and quotas.
Free handles core backup/restore; Plus covers BYO cloud; Pro covers remote import, empty-server installer, Staging, and split/extract. Pick the tool that matches the failure — do not upgrade tiers hoping a cloud auth typo will disappear.
After the archive completes
If the local archive is good, you can restore even when cloud upload failed. Fix destination auth/quota, then re-upload, or restore from local. On Staging, confirm HTTPS, mapping, media, and logins before production.
If mid-restore failed, do not “fix” production DNS first — finish Staging validation and confirm table/prefix expectations.
Retention, encryption, and support hygiene
For fix restore white screen, keep enough archive generations to roll back a bad deploy or failed migration. Optional .venc AES-256 encryption on Multisite Migrate archives protects copies at rest when you store offsite on Plus destinations. Document credentials, schedule windows, and who may run Network Admin jobs.
When opening a support ticket, include the last job log lines, hosting class, PHP limits, free disk, and whether a local archive already exists.
Runbook reminders for Multisite backup ops
For Fix Restore White Screen, keep Jobs in Chunks enabled, retain enough archive generations for rollback, and prove recovery on Staging before production cutover. Free covers core backup/restore and one local schedule; Plus adds BYO cloud (Drive/Dropbox/S3-compatible/SFTP); Pro adds remote import, empty-server installer, Staging, and network split. Record job log lines, PHP limits, and free disk when something fails so you do not rebuild a finished archive unnecessarily.
Why this matters
Log-first diagnosis
Identify whether the failure is PHP, disk, DB, cloud, or URL rewrite.
Chunking as the default fix
Resume instead of restarting huge Multisite jobs from zero.
Restore-side checks
Separate backup failures from post-restore URL/media/login issues.
Support-ready evidence
Know which log lines and environment facts to capture for support.
Steps
-
1Capture the failure point
Record job percent, last log line, HTTP status, and hosting type for “restore white screen” before changing settings.
-
2Apply the matching fix
Raise safe limits, free disk, fix credentials, or allow AJAX through WAF — based on the log, not guesswork.
-
3Re-run chunked
Resume the job. Avoid overlapping schedules that collide on locks or wipe tmp mid-run.
-
4Confirm local archive integrity
If the archive finished, note its size/path. Cloud upload can be retried separately from rebuilding Multisite tables.
-
5Validate restore path
Test import/restore on Staging. Check URLs, media, logins, and mapping before production changes.
Frequently asked questions
Quick answers for this Multisite backup topic. Still stuck? Open the docs or contact support.
Should I raise PHP limits forever?
Safer limits help; Jobs in Chunks remain the durable fix when hosts interrupt long requests.
Why did the job restart at 0%?
Often tmp cleanup or a new job ID. Confirm the previous lock is gone before starting again.
Cloud upload failed but local archive exists?
Fix destination auth/quota, then re-upload or rely on the local archive for restore.
Is “restore white screen” usually backup or restore?
Split the problem: job log for backup failures; Staging URL/media/login checks for restore failures.