Moving A Server – Things You Need To Know

Over the years I’ve been involved in a lot of server moves and I’ve been asked to ‘fix’ a few that have gone awry. By far the biggest problem has always been lack of planning. If you plan your server move carefully then you have every reason to believe it will go fairly smoothly. If you don’t plan at all then there’s a very good chance that you’re going to strike some problems. Here’s a summary in point form of the procedure I follow when moving a server.

Firstly, I should say that moving a server is not necessarily a trivial thing. Moving files and importing/exporting databases is fairly easy but you need to consider everything including whether your new site provides the same environment that your old site had. Does it run the same version of PHP? Will your site run okay with MySQL 4 or does it use some of the features that are only available in MySQL 5? If it’s a very basic site then you should have no issues at all and the move will be quite easy. If you have scripts that use PHP, MySQL or Perl though you might find that there are some things missing or different at the new site that will need to be addressed before you finalise the move.

* The easy way is to do a complete backup if you are using CPanel and then restore that backup on the new server. If you can’t do that, then you need to follow the steps I’ve outlined below.

* Take a backup of the old server and check it. One of the problems you may have is with large databases. Online database programs such as phpMyAdmin can only back up a certain amount of data before your browser or the web server times out. If this happens then you need to either login with SSH and do a ‘mysqldump’ at the commandline or ask your web host to do it for you. Keep in mind that if the web host does it for you, your data will only be current to the time the web host exported it for you – so if it’s a fairly dynamic site or you have active forums you should be (a) warning your members that some posts may be lost and (b) arranging to get this export done as one of the final steps before you actually move the site.

* If you are using PHP and/or MySQL, check the versions of both of those and also the PHP configuration. With a phpinfo() command you can get a full list of all of the features and extensions that are compiled into PHP. This is another common problem … where one server runs PHP4 and the other has PHP 5, or some of the extensions on the old server aren’t compiled into PHP on the new server.

* If you have any Perl scripts then you need to check that all the Perl modules your site uses are installed at the new site. Perl has a very large range of modules, so there’s a chance that some may need to be installed at the new site.

* The next hurdle to get over is the fact that you need to set up the new server using an internet address that points at the wrong place. What I mean is that if you have www.yourserver.com (the old server) and the new server is going to use the new address, you need to be able to set the new server up as www.yourserver.com even though that address is pointed at the old server. What I generally do is use the Windows hosts file. It is located in your system32 directory in drivers/etc. You can add the web address and the IP of the new server, then flush your Windows DNS by going to a Windows commandline and entering the command ‘ipconfig /flushdns’. Then, close and re-open yourweb browser and it should bring up the new server when you enter the web address. If you need to look at the old site again you can simply remove the entry in the hosts file, flush the DNS again etc. The idea though is that once you have the backup you shouldn’t need to look at the old site again until you’re ready to put up a ‘we have moved’ page.

* Next up, we copy all the files up to the new server, import the database and see if it is all working. You may find some problems or glitches – give it a good test and if you have any forms or scripts that do file uploads, image creation etc, make sure you check those as well.

* Once you’re satisfied that everything looks to be working, you can change the main page of the old site to read something like “We have moved. It may take up to 72 hours for the change of DNS address to reach you so please be patient. Once the new DNS details reach you, you will be able to see the site again”.

* The final step is to change the nameserver addresses at your domain registrar (the place where you registered your domain). That will tell the DNS that your server has moved to a new location.

So, there you have it. I haven’t written this in ‘laymans’ terms because I honestly think that anything but the most basic server moves should be left to the ‘professionals’. If you understand everything I’ve said in this post then by all means, do your server move. But if it all looks a bit too hard then there’s a good chance that it will be too hard for you, in which case you should have an experienced IT pro do the server move.


Server Tuneup – Email

This is the first in a series of tips that will delve into CPanel and soem of the options you have. The first one I’m going to look at is the ‘default email address’.

If you look in the email section of CPanel you’ll see this option. Depending on which version of CPanel is installed, you may see it as a ‘Default Address’ icon or you may need to first click on ‘Email Accounts’ to see it.

You should have 3 or options (you might need to click on ‘Advanced’ to see the third option) but we will look at the main three. In CPanel 11 you can ‘pipe’ messages but that is for advanced users and rarely used.

First, lets talk about what this ‘default address’ is. The default address is a ‘catch all’ address that will receive email for any email address that isn’t actually defined. So, you may have a few addresses like bob@… and sally@… but what happens if an email comes in for fred@…? That’s where the default address comes in. The email to fred@… will be delivered to the ‘default address’.

There are a few reasons why you may want these messages delivered into a mailbox, but generally speaking you will want to discard them. This is mainly because many spammers will send emails to non-existent addresses at your domain in the hope that they are delivering to a real person. This is called a dictionary attack where they take a list of several thousand names and send email to all of those names at your domain.

Bouncing the messages is considered to be the technically correct thing to do though there are some who frown on this as it simply creates more email out on the Internet and if the incorrectly addressed emails are coming from spammers then they aren’t going to even read the bounce messages anyway. Also, there will probably be a time when a spammer forges an address at your domain as the reply address on spam emails in which case your server will receive many bounce messages as well … which it will then respond to with more bounce messages.

Fortunately, CPanel allows you to deal with these message without creating more messages. The option (in CPanel 11) is ‘Discard with error to sender (at SMTP time)’. This looks at the address that someone is trying to send to and if the address does not exist it simply responds with an error message ‘no such user here’ and closes the connection. It’s basically like when you ring a wrong number on the telephone. The person at the other end picks up, tells you that the person you are calling is not at that number and the call ends.

The one exception to this option is if you are experiencing a sustained, heavy flow of emails to invalid addresses. In this case you may want to select the option that says ‘Discard (Not Recommended)’. In earlier versions of CPanel this is the ‘:blackhole:’ option. Discarding with no error response will lower the amount of CPU and resources required for each invalid messages and may prevent your server from slowing right down or even crashing. If this does happen and is sustained for more than an hour or two then you really should contact your host or a server professional to take further steps in preventing these email messages from getting to your server.


Choosing A Dedicated Host

Filed under Server Tips | 1 Comment

As is the case with most services, the quality of hosting providers varies greatly. I have used several hosting services, both shared and dedicated, and also operate my own small server ‘farm’. These recommendations are based purely on my own experience as well as experience I’ve had working on servers at other providers.

The first and most important advice I can give you is to beware of resellers. I’m not going to say that all resellers are bad. After all, many resellers are, like myself, people who have been active in the IT industry since before the Internet became a commercial ‘space’. Still, I often find that I am providing server management services simply because the hosting provider is a small business person who knows little about IT and just doesn’t have the knowledge or skills to provide any meaningful advice or support.

By way of recommendations I am going to provide a short list of hosting companies that I know, from my own experience, are professional hosts with qualified technical staff that are able to provide you a satisfactory level of service.

Rackspace – These guys are probably the ‘Rolls Royce’ of hosting companies. If you have the money to spend then you will enjoy their ‘fanatical service’. Rackspace have their own data centers and can provide advanced configurations such as load balanced server clusters. An expensive option but the support is unequaled.

Layered Technologies – I have three of my own dedicated servers with Layered Technologies and I can say that the support has always been excellent. Turnaround time on support tickets has never been more than around 8 hours (quite often less than an hour). Layered Tech also offer many configurations from basic dedicated servers to load balanced clusters and even your own ‘virtual data center’. They also accept PayPal as a payment method for monthly fees. LT also have specials from time to time. I needed a low end server some months ago and was able to get a reasonably fast server for $75/mth.

– Like most large hosts, HostGator seem to have a ‘love ’em or hate ’em’ reputation with some people. I’d venture to say that the people who like HostGator far outnumber the small percentage who don’t. I have some shared hosting on their service and I also manage several HG dedicated servers. Their service has been as responsive as LT, with a very fast response to tickets and they’re more than happy to do some diagnostics for you if you feel that your server is slowing or misbehaving.

Lunarpages – I had a shared hosting account with Lunarpages for around 12 months (until I realised I had waay too many shared server accounts)! Lunarpages are one of the most professional hosts I’ve dealed with. Prompt support, excellent uptime and very affordable. Their servers are fast and they provide a great range of features for various scripts and applications that you may want to have hosted on your site. I have no hesitation at all in recommending them as I didn’t have a single issue during the time I had sites hosted on their servers.

GMD Hosting – I manage several servers that are hosted at GMD. This is a hosting company operated by Pat Lovell and Jon Atwood, a couple of guys who are well known in Internet marketing circles. Both had been providing their own hosting services, which they amalgamated this year. The result is a reasonably priced range of hosting plans for a company with a competent technical staff and a very successful marketing background.

Technorati Tags:


Migrating To A Dedicated Server

Over the years I’ve often had to move websites from one server to another. It’s not rocket science, but if you don’t have a plan and a very clear picture in your mind of exactly what you need to achieve then it can go pear shaped fairly quickly. So, here’s my ‘standard plan’ for moving a server that runs some sort of script (i.e. directory site, traffic exchange etc) and a MySQL database. Let’s assume the old domain is domain.com and the new IP number is

Step 1: Send an email to your member list 48 hours before the move.

Step 2: Create the domain.com account (CPanel etc) on the new server.

Step 3: Take a full backup of all data on the server and all data in the MySQL database(s) and restore them on the new server. Restore the MySQL database(s).

Step 4: Edit your windows hosts file (C:\WINDOWS\system32\drivers\etc\hosts) and add an entry for domain.com with the new IP address.

Step 5: Flush your windows DNS cache (open a CMD window and enter the command ‘ipconfig /flushdns’).

Step 6: Open your browser to domain.com. It should now be opening on

the new server due to the hosts file entry. Just to be sure, place a comment in the home page file (index.html/index.php) like <!– NEW SERVER –>. That way, you can just view the source of the homepage to verify that you really are on the new server.

Step 7: Test EVERYTHING. Test the script. If it has an admin area, test the admin functions. Follow all the hyperlinks and make sure that everything is working correctly.

Step 8: Once you are sure the new site is working correctly, place an alternate homepage on the old server that says something like ‘We are moving to a new, faster server. We apologize for any inconvenience this may cause’. Now reboot the (old) server. This will kick anyone out that is currently logged in.

Step 9: The files should all be okay (unless you have some sort of funky file-based database). Now it’s time to take the ‘real’ database backup. You don’t want anyone losing anything, so you need to take a backup of the database again at the point where you prevented people from logging in.

Step 10: Delete the database on the new server and do a restore of the database backup that you just did from the old server. You now have the most current database data and everyone should be happy when they get to log back in.

Step 11: Update the DNS at your registrar to point at the new DNS servers.


There you have it. Eleven easy steps to a smooth server move :). You may get the odd person who says that they got to the new server but then it went to the old one again. That will be something to do with the DNS propagation and can be safely responded to with ‘give it a little while longer and all will be well’. If you still see or are alerted to problems after 72 hours then there may be something up with the DNS config on the new server but it would have to be a fairly obvious mistake and easily rectified if that were the case.