You can copy a site from one server to another server. Once the site is on the new server you can change the domain name if you wish.
Important: You should only copy the same site to a target server ONCE. If you do it again, the original copy will get overwritten. This is because the tables, database name, users etc are the same as the original site. Copying the site again to the same target server will overwrite any changes you have made on the target server for the prior copy of that site.
To copy a site to a new server:
A popup will appear that will offer periodic feedback as the cloning process progresses.
When the process is complete you will get a popup confirmation message and the black ‘terminal” window will show the actions that were taken while copying the site. You can also see this information in the COMMAND LOG screen.
Please make sure that there is enough disk space on both the current server and the target server to clone the site. We recommend at least TWICE the space as the site currently occupies:
For example, if the site is 100MB, then you need an additional 100MB on the current server and 200MB on the target server. This is because the files are compressed into an archive before being copied to the target server. So you need space on the current server to compress the files and then you need space on the target server to decompress them.
If the copy fails because of a lack of disk-space, your new site might be left in an undefined state and you will need to use our PAID support resources to help you clean up the site on your server.
When copying large sites, you might see some “file not found” errors in the terminal. This is because it is taking a very long time to copy the files and, while that is happening, there is no output being sent to the log files.
If you know that your site is large then you should be patient and let the process run for a bit pass all those error messages.
We attempt to push your sFTP users for the site to the target server. However, if you have two sites on different servers with the same user name, things could get wacky on the target server. So, as a best practice, consider having unique names for your sFTP users across all your sites on all your servers. This way when you start pushing things around you don’t end up with user names that step on each other.
With this feature there are a few significant caveats:
You might see the following messages in the logs after a site is pushed to a new server:
Job for nginx.service failed because the control process exited with error code. See "systemctl status nginx.service" and "journalctl -xe" for details. Site Sync Completed Successfully.
This means that the site has been copied but there is now a conflict in the NGINX configuration files that prevents the server from being started.
Usually, this problem is because of a long-standing conflict between NGINX, CERTBOT and IPV6. (CERTBOT is the service responsible for issuing SSL certificates.)
The short story is that NGINX only wants one IPV6 statement in its configuration files across all sites. And CERTBOT is smart enough to know this and will make sure that only one site has this configuration item enabled. BUT, when you push a site to the new server, CERTBOT knows nothing about this. So it is possible that the site you pushed has this item in it which will conflict with any existing sites on the target server that also has this configuration item in it.
So, the fix is as follows: