Created a backup on hosted server using WPVivid. Started Local site (already a version of the hosted website) and attempted restore of the backup to the local version. First file reaches 100% and then error message ‘File type is not allowed’.
Contacted WPVivid who suggested copying the backup files to the appropriate directory and then running the restore. Works fine.
So problem is with the Local upload process? Log attached includes other backups and restore using the workaround supplied by WPVivid so the error related to 2026-07-27 at 12.52
What steps can be taken to replicate the issue? Feel free to include screenshots, videos, etc
Security Reminder
Local does a pretty good job of scrubbing private info from the logs and the errors it produces, however there’s always the possibility that something private can come through. Because these are public forums, always review the screenshots you are sharing to make sure there isn’t private info like passwords being displayed.
There are 11 zip files which make up the backup: 4 uploads, 3 plugins, one each for db, theme and core.
The error occurs on the first file, which is not always the same one but looks like it is the last one created that goes into the process first.
I think there have been some issues with WPVivid due to this before. Generally, what Local expects in the zip is just the WP-Content and SQL bundled together, but I wonder if it’s having trouble with all of the files spread out.
I haven’t used WPVivid myself but essentially you were trying to do a backup restore using the plugin from a hosted backup to your Local instance. Is that correct?
Your log isn’t showing anything too insightful as far as any recent errors or anything like that but we can try to help and continue to narrow this down. Could you share your full Local Log with us as well? If you click on the Question Mark (Support) tab on the left side of your Local app, you’ll scroll down and see a Download Local Log button there that collects everything in a zip.
You might also run through some Windows checks to ensure there aren’t any security, permission or firewall blockers.
I’m not seeing much else in your log aside from maybe some connection interference
2026/07/28 16:38:46 [error] 7852#30468: *247 connect() failed (10061: No connection could be made because the target machine actively refused it) while connecting to upstream, client: ::1, server: siteworks-demo.odp, request: "POST /wp-admin/admin-ajax.php HTTP/2.0", upstream: "http://127.0.0.1:10011/wp-admin/admin-ajax.php", host: "siteworks-demo.odp", referrer: "https://siteworks-demo.odp/wp-admin/index.php"
Is there anything unique about your network? Since the restore didn’t work until you loaded the files locally maybe it wasn’t able to make a stable enough connection. Do you use a VPN, hotspot, office network or network proxy of any kind?
Just plain PC with a fibre to the premises gigabit link, no VPN, hotspot, office network or network proxy of any kind at my end, although i can’t vouch for the provider not having perhaps a proxy.
However, I have been running this backup and restore to LocalWP successfully for over 2 years and this issue has only arisen in the last couple of weeks, so nothing has changed at my end.
Thank you for that context @owenparry! Have you successfully restored this site before? Or just had it work for other sites? Would there be anything unique about this install different from others as far as size or configuration?
I’ve just tried a completely new site using a zip file provided by our theme developers (https://siteworks.u3a.org.uk/), added WPVivid plugin and restored to it. The upload stage failed as before but moving the backup files to the folder and then restoring worked OK.
The only thing that seems to be different is that we moved to WordPress 7.0.2 recently as a security update for wp2shell vulnerabilioty.
One point I should add is that previously, WPVivid backup produced 4 - 5 zip files named with suffices of part1, part2 etc. Recent backups have produced many more files (11 in my case), separating uploads, content, core, db and themes into separate zip files.
Not quite sure when this occurred but it must be fairly recently as I have an old-style backup dated 16th June 2026.
@owenparry are you utilizing the free version of WPVivid for this? I can attempt to replicate the behavior and see if there is a bug we could file from our end, but glad to know that manually importing still works as an alternative for now.
Have you tested this with Windows Defender disabled? Since the file reaches 100% before failing, it’s getting through the upload but failing validation so Windows Defender or antivirus might be scanning/blocking the files mid-upload.
You said this started after updating to 7.0.2. Would you be able to roll back and test on a previous WP version? You could use this plugin if needed: Core Rollback – WordPress plugin | WordPress.org
You also mentioned that WPVivid backups recentlly changed their backup structure. Are you able to test an older backup or an older version of WPVivid to see if that is any different?
Sorry, I have limited resources and am unable to handle this. However, there is continued discussion amongst other organisations using WPVivid which may mean the problem is referred back to them anyway.
