WPCloud Deploy Documentation

Copy Site To Another Server

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 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:

  • Go to WPCloud Deploy->Applications
  • Click on the site for which this action will apply
  • Click on the Copy To Server tab
  • There should only be a single section on this screen.  Select your target server from the drop-down list of servers.
  • Click the Copy To Site button
  • Click the OK button in the confirmation window

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.

Before Copying A Site

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.

Copying Large Sites

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.

Other Notes

  • If you are copying the same site multiple times to the same server, make sure you DELETE the site from the target server prior.  You can do this using the REMOVE SITE option under the MISC tab for the app on the target server.  If you do not do this, you could end up with duplicate APP records on the target server. 
  • If you have server sync enabled, make sure that you don’t choose a serve-sync destination server as the target server!
  • We strongly suggest that you clear the OBJECT CACHE (such as MemCached or REDIS) if it’s enabled on the target server.
  • You can only copy sites between servers that have a ‘root’ login.  SUDO logins such as ‘ubuntu’ will not work (which means that you cannot copy sites between servers for providers such as AWS and GOOGLE CLOUD)

Issues


NGINX Web server fails to restart on the target server after a site is copied.

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:

  1. ssh into your server
  2. Navigate to /etc/nginx/sites-enabled.
  3. edit the configuration file for the site you just pushed – eg command to edit a site named “mydomain.com”: nano mydomain.com.
  4. Scroll down to the line that has this item on it: listen [::]:443 ssl ipv6only=on; # managed by Certbot
  5. Remove the ipv6only=on text.
  6. Save the file.
  7. Start NGINX with this command: service nginx start.

Share: