bcrodua

Hi @swapot

Thank you for following up. From checking the logs you provided earlier, what stood out was that the restoration process was getting stuck during the database restoration step. That typically suggests the database might have been too large or contained some overhead that slowed down or disrupted the process.

Before attempting a new restore, I recommend optimizing the database first using a plugin or tool of your choice. This can help reduce its size and clean up unnecessary overhead, making the restoration process smoother.

Let us know how it goes after trying this.

Best Wishes,
Bryle

Hi @swapot,

Thanks for reaching out and sharing the details.

From your description, it sounds like the restore was incomplete, likely due to server timeout or restrictions. That can result in login redirects or other site issues, especially if the database restore did not fully complete.

Please could you try the following steps:
— Access your staging site via FTP or File Manager and rename the wp-content/plugins folder to temporarily disable all plugins.
— Then try accessing wp-admin again and check if it no longer redirects.

If the login works after this, you can rename the folder back and reactivate plugins one by one.

Regarding the restore timing out:
— You may need to increase your PHP max_execution_time and memory_limit settings, or check with your host if there are any server restrictions in place.
— If possible, try restoring fewer components at a time (Just make sure to restore the database last) rather than all at once.

Let me know how this goes.

Best Wishes,
Bryle

Hi @oaz ,

Thank you for following up.

Could you please try downloading the backup files directly via FTP from the wp-content/updraft folder and check if their file size is really showing as 0 KB on your local machine? Sometimes the file manager or backup report may show an empty size even though the files are actually present.

Best Wishes,
Bryle

Hi @ajw1100

Thanks for the update and for taking the time to test and clarify everything — much appreciated.

To confirm, having multiple sites backing up to the same Dropbox account is okay, but problems can arise if those sites are configured to save into the same remote folder, especially if they were cloned or restored from each other. This can lead to confusion or overlap in identifying backups. Ideally, each site should have its own subfolder in Dropbox (this can be set under Settings > UpdraftPlus Backups > Settings > Remote storage).

As for the issue with your Local site backup stalling at 16%, this could be related to:

• A Dropbox API timeout or limit (especially if Dropbox is throttling requests).
• A file too large for your current connection or system resources.
• A local configuration or conflict affecting the backup process.

Here are a few suggestions:

1. Try reducing the archive split size in UpdraftPlus > Settings > Files backup options > Split archives every… (try setting it to 50MB or 25MB).
2. Try a different remote storage like Google Drive or OneDrive, as you mentioned. That can help determine if the issue is specific to Dropbox.
3. If you’re willing, feel free to upload your log file (from Notepad) to https://pastebin.com, click “Create New Paste”, and then send us the URL you get after submission — that will allow us to read the log.

Lastly, no need to worry about technical depth — you’re doing a great job already!

Best Wishes,
Bryle

Hi @thegreatdanton

Thanks for sharing the log. The restore appears to complete the database and main site content successfully. The only issue shown relates to restoring the mu-plugins folder—your server blocks rename() due to a cross-device link restriction, but UpdraftPlus automatically falls back to a recursive copy, so restoration still proceeds.

However, some MU-plugins (like cache or platform-specific tools) may cause a “critical error” once restored.

To fix this:

1. Temporarily disable the mu-plugins folder via SFTP by renaming wp-content/mu-plugins/ to something like mu-plugins-temp, then check if the site loads.
2. You can also restore again with the “mu-plugins” option unchecked, and re-enable them manually after confirming the site is working.

Let us know how it goes!

Thanks,
Bryle

Hi @ajw1100

Thanks for the update.

To better understand what’s happening, could you please send us the full copy of the backup log? Go to Settings > UpdraftPlus Backups > Backup / Restore tab. Click “Show log” next to the most recent backup. Scroll to the bottom and click “Download log file”. Then upload the log to https://pastebin.com and share the link here.

Also, to help prevent issues, please try reducing the split archive size by going to:
UpdraftPlus Settings > Files backup options > Split archives every…
Set this to something smaller like 25MB or 50MB, then save changes and run the backup again.

Let us know once you’ve uploaded the log!

Best Wishes,
Bryle

Hi @ajw1100 ,

Thanks again for the update—and great job finding the backup files in Dropbox!

Yes, you’re on the right track. Each backup is made up of several parts (plugins, themes, uploads, database, etc.), and the files are usually split into smaller chunks.

Each file follows a name format like this:
Backup_date_time_yourwebsitename_random_componentname.zip
Example: backup_2025-07-03-2354_yourwebsitename_6881395494cf-db.zip
This helps identify when the backup was made and what component it contains.

So yes—you’re correct that backups from the same date will have multiple files, one for each part of the site.

To safely clean up:
Identify the backup dates you want to keep (e.g., the two most recent dates).
Delete all backup files with older dates.
Keep all files that share the same backup date/time for the sets you want to retain.

Best regards,
Bryle