Over the last few weeks I’ve done 3 server migrations. The first was a one-to-one upgrade, moving from an older server to a new one. The last two have both been two-to-one migrations: taking 2 vps’s (4 total) and consolidating to 1 dedicated (2 total).

In the first migration, we off-loaded DNS to DNSMadeEasy for management. I’ve advocated DME for the last couple years as a way to offload services and tighten security on a web server. They’re very cost-effective, have a quality service and are up 100% of the time due to their architecture. The biggest challenge was our attempt to build an IPSEC tunnel with Racoon to a Linksys RV042 router, which failed. Although we could see Phase 1 complete, Phase 2 failed regardless of how basic we made our configuration. Should someone have the secrets for getting CentOS and IPSEC to talk to a Linksys RV042, please share it with the world…

My second migration had off-site DNS of a different variety–which was quite cool as I simply made requests to the service provider and they filled the order.

In the third migration, we hosted DNS on the 2 VPS’s. This was quite fun as cPanel allows for Clustering of name servers. I made full use of this by syncing DNS data between all three servers. For practice, I redirected all of the DNS for one of the VPS’s to the new servers’ IP’s, added the proper data to the /etc/named.conf file that told the name server it was SOA (Master) for those domains, and shortened TTL’s to make site transfer and their inherent downtime manageable and negligible. This was also the source of my biggest oops: I forgot to update named.conf with this “master” information for the second server, which caused about a 4 hour outage.

Those were the primary differences in the migrations.

Although these migrations all coincided in a short time frame, I got control of the servers at different times. The similarities are that all three servers are running CentOS (one on version 5.2, the other two on version 4.6) and the initial setup.

Initial setup:

• Install and configure CSF
• Change sshd listening port
• Walk through cPanel/WHM setup and modify for specific needs
• Add mod_sec, suhosin, clamav, and recompile apache2 with needed extensions and php version
• Set mysql root password

Once satisified with base configuration, I started transferring sites. Here, one of my daily tools came in very handy: Roboform. Even if you don’t purchase the full version, its ability to fill in a form makes it very worthwhile.

To transfer sites, I used the following method:

• Add SSH port of far end server to Outgoing TCP in CSF
• Access sites cPanel as root user (so that drop down box appears); ignore warning
• Go to Backups >> Download or Generate a Full Backup
• Select Secure Copy (scp) from drop down menu
• Set email address as appropriate
• Fill in Remote Server (either IP address or FQDN)
• Fill in Remote User (in my case I used ‘root’)
• Provide Remote Password
• Set Port (same as the sshd port of the far end server)
• Set Remote Dir to /home/
• Generate Backup

If using RoboForm, all of this can be captured into an Auto-fill function for re-use, which is very convenient if you’re transferring a number of sites. All told, I transferred over 90 sites and RoboForm saved me a ton of time and typing.

• On the new server, in WHM >> Backup >> Restore a Full Backup/cpmove file, put the username in the proper box and “Restore”.

Fortunately, WHM/cPanel makes it easy to determine the username: it’s listed after the date_ and before the .tar.gz.

Do pay attention to the restore window in WHM as a site builds…occasionally there are problems and most of them show up as an error. It’s also a very good idea to check the site and make sure that “it’s there”. There may be other issues, such as old, out of date scripts being transferred to a server that’s running new services; these may not be found until a change is attempted.

For one site, running MediaWiki, I wanted to update the package to the latest and greatest before I transferred it. Unfortunately, this didn’t work because the old server wasn’t running the correct version of PHP. Which segues into another “time saving” technique: before updating or upgrading a site, use the same technique above except to keep the backup tarball local. Then if your upgrade fails, terminate the site and re-install from your current backup. Make sure that you’ve moved the tarball outside of the users’ home directory though…terminating will destroy EVERYTHING in that users home directory, including backup files.

If for some reason you need to reinstall a site and you can use the current backup, you’ll need to move it from the /home/cprestore directory back to /home for WHM to see it. Here again, if a site fails to restore properly and the user has been created, you’ll need to “terminate” that user before attempting a new restore–whether from a newly transferred backup or a copy already located on the server in one of the allowed restore paths (noted in WHM).

Finally, if you’re hosting DNS on your cPanel server and you’ve set it up for clustering, it’s best to disable synchronizations BEFORE removing a site from the old server. Otherwise you may need to add a new DNS zone on your new server as synchronizing services, which is a part of the “terminate” process, will wipe out that zone where it’s needed most: the new server!