Sure, but first I would like to know on what part does the error occurs. Does the error happens while uploading? Or does it happens only after uploading?
The 1.0.4 beta version deals with the fixes on server timeout on processes after the uploading part. So if it times out while uploading, you might want a connection with higher upload speed and see if it works.
Also with the size of 2GB, you can try to minimize that by deleting unused files in your uploads directory which is no longer needed on the target site.
I’m preparing the download link for the test beta, give me around an hour to prepare thanks.
It happens during upload, so I guess I’ll just try a higher speed network first, and see if that works. If not, then I’ll try your advice to reduce to size of the file. Thanks!
Yes, reducing file size helps a lot. There is also another possible solution which is available in the pro version. Prime Mover remote restore url feature:
https://codexonics.com/prime_mover/prime-mover/how-to-export-and-restore-using-pro-version/
It works like this:
- Generate export package(you already done this)
- Upload Prime mover package zip using your favorite SFTP client to your target site WordPress root directory. So that the resulting path is like https://yoursite.com/myprimemoverpackage.zip.
- Activate Prime Mover Pro on your target site.
- Go to Tools -> Migration Tools -> click Import -> click Restore backup zip from a remote URL and the paste the URL to your zip which is now inside your site.
- Prime Mover fetches the zip which is now inside your server and it does the rest of the restoration process
The above solution is preferred when browser uploading is not reliable (especially for big files) and you have limited speed. SFTP uploading is usually better than plain browser uploading which can be slow.
This is the link to download the latest 1.0.4-beta.
It includes fixes on server timeouts for both export / import process. I suggest to use it when you restore the site (at target site). In case you need to re-generate export which has smaller uploads size, please also use that new beta version for now. It’s almost stable version and it will be released here in WordPress repo as early as next week.
Thanks and let me know if you are still having issues with restoring the site.
@mhurwicz Regarding your latest issue posted here: https://wordpress.org/support/topic/invalid-site-footprint-while-exporting/#post-11854942
I assume you have gateway timeout errors while importing/uploading.
I suggest this fix:
- Restart your PHP / Apache. This will stop any ongoing process running so it will be back to normal.
- If target uploads is outdated and no longer used, you can delete /wp-content/uploads/ it to save space (so it will be replaced with target site)
- If you want to upload a very big file (> 1GB),please add this to your wp-config.php at the target site (where the import will be done):
define('PRIME_MOVER_UPLOAD_REFRESH_INTERVAL', 5000);
This will send a fewer upload requests to your server to avoid timeouts and overloading it causing gateway errors.
- Please use beta 1.0.4. You can download it here. when restoring the site.
Yesterday I tested >1GB on an upload connection, the same as yours. It was able to install using version 1.0.4 beta using that wp-config.php constant added. Can you please try it and see if it works for you?
Please let me know how it goes. If you have a new unrelated issue, please create a separate ticket. Thank you!
> I assume you have gateway timeout errors while importing/uploading.
It happened after I exited the page, because I thought Prime Mover had stalled. So uploading going on.
> I suggest this fix:
> Restart your PHP / Apache. This will stop any ongoing process running so it will be back to normal.
When I try to restart Apache with this command:
sudo /opt/bitnami/ctlscript.sh restart apache
I get:
Failed to unmonitor apache: write /var/lib/gonit/state: no space left on device
Syntax OK
/opt/bitnami/apache2/scripts/ctl.sh : httpd stopped
Syntax OK
/opt/bitnami/apache2/scripts/ctl.sh : httpd started at port 80
Failed to monitor apache: write /var/lib/gonit/state: no space left on device
> If target uploads is outdated and no longer used, you can delete /wp-content/uploads/ it to save space (so it will be replaced with target site)
Not sure if I understand what you are saying, but it kind of looks like the zip file uploaded fine. Screenshot from Filezilla:
http://prime-mover.s3-website-us-west-2.amazonaws.com/
(This is in a subdirectory of the prime-mover-import-files directory. The name of the subdirectory starts with the beginning of the blog name, and ends with the blog ID number.)
Also, in the the prime-mover-import-files directory there are tons of .part files. Maybe those are the ones I should delete?
I’m not able to try another upload at this point because I can’t get into the Network Admin — though sub-sites are working again (not sure what changed). The main site is now back to redirecting to static IP signup page with “Registration has been disabled,” as described here:
https://community.bitnami.com/t/redirects-from-main-domain-to-static-ip-sign-up-then-says-registration-is-disabled/70572
-
This reply was modified 4 years, 11 months ago by
mhurwicz.
Yes, can you please delete all .part files inside /prime-mover-import-files/ directory?
Once you delete it, try restarting Apache and see if you can now access the Network Admin.
If the issue still persist (you still get no space left on device error), try deleting all files inside /prime-mover-import-files/, including the uploaded files. And then restart Apache again.
This should free up some space in your server and you should be able to access network admin.
If that won’t resolved, we need to understand this issue deeper in your site, in this case I suggest to contact us in our official site and request for technical support.
Since this is a public forum, and we could not debug issues here in details.
Michael, I’ll close this ticket here since you now have access to premium support. Let’s follow-up there. Thanks!
