Question

A small organization hired you to migrate the company’s web server that is running in a windows 2008 server to a new server running windows 2012 server. The current server does not have any kind of hardware redundancy.

1. Provide a couple solutions that you can implement in the new server to build a server with the required redundancy to avoid service(s) outages
2. Provide a high-level description of the main steps that you need to follow to properly migrate the customer data from the old web server to the new web server

Answer 1

A))

An automatic server failover solution is surprisingly easy to setup. It works by having two servers with identical content on them – a primary server and a secondary server. A third server monitors the primary server and detects if there is a problem. If there is, it will automatically update the DNS records for your website so that traffic will be diverted to your secondary server. Once your primary server is functioning again, traffic will be routed back to your primary server.

Setting up an automatic server failover solution just consists of 5 steps:

1. Get a secondary server

The first thing you need is another server to be your secondary/failover server. This doesn’t need to be a dedicated server – if you’re using shared hosting then another shared hosting account will do just fine. However it is important that you choose a server that is physically different from your primary server. I recommend not only using a different hosting company, but also making sure that the servers are in different locations.

What good does a secondary server do if its using the same network as your primary server when it goes down? Or if a server admin makes a goof that’s propagated to all servers they manage? Before I sign up with any new host I’ll research where they’re located to make sure it’s not in the same state as my primary server. You can use the IP Information tool here to check the location of any ip address. If you don’t know where to find a good secondary server host.

2.Synchronize primary and secondary servers

• Syncing website files

There are two common approaches I typically use to keep my website files in sync: Rsync and Source Code Repositories.

Rsync is a unix utility that synchronizes files and directories from one location to another. You run a simple command similar to “rsync server1:/myfiles server2:mybackupfiles” and it will copy everything inside ‘myfiles’ from server1 into the ‘mybackupfiles’ folder on server2. It also saves time and bandwidth by only copying over what is different, pretty cool!

You’ll run a command similar to this on your secondary server. Be sure to use the IP address of your primary server instead of the host name since the host name could refer to the secondary server when failover has kicked in (that’ll make sense later). I’d suggest mirroring everything in the public html directory.

• Syncing databases

If your website replies upon a database, such as wordpress does, then you’ll also need to copy over the database, which is separate from the file copy you’ve just set up. Technically you could try to just copy over the database files, but I wouldn’t recommend that – it could create inconsistent data in the event of an error. I’ll show you how to copy over the contents directly from within your database program.

We’ll use MySQL for this example, but all database systems should have similar commands. You’ll first need to have a blank database set up on the secondary server with the same name, user, and password as the primary server’s database. Then we’ll utilize the mysqldump utility to spit out the contents of the primary server’s database and feed it directly to the copy. This command should be run from the secondary server

3.Reveal server status

The tool we’re going to use to automatically switch your servers upon failure needs to know when your server is failing. It does this by checking your server every few minutes for a specific response. You can have it check just your homepage to see if its serving content, but I like to get a little more detailed. For example, your website may still return a page if your database is down, which would be a false indicator that everything’s okay when it’s not.

I recommend creating a server status page that reveals if ALL services are functioning properly. Make a simple script that connects to the database and returns ‘SUCCESS’ only if the connection was successful. This ensures that HTTP and database services must be functioning properly to report a successful server status. If there are other services your site depends on, include a check for those too.

4.Set up DNS Failover

We’ll be using a service called DNS Made Easy to provide DNS Failover. This automatically checks your server status script every few minutes for ‘SUCCESS’. In the event your server is unreachable, or there’s some other error and it doesn’t see ‘SUCCESS’, DNS Made Easy will change your DNS entries to point to your backup server. As soon as your primary server is reachable again DNS Made Easy will revert the changes back to your primary server . Since your visitors are accessing your site via your domain name, no one will ever know what just happened as they’ll have been pointed to a functioning server the whole time!

5.Test it

Make sure you wait at least 2 days before testing this – it will take 24-28 hours for your initial DNS transfer to DNS Made Easy to propagate through the internet. To test, simply rename the server status script so that the monitoring cannot find it. Within 2-4 minutes, you’ll receive an email alerting you that your site is down (you’ll actually receive 2, one for each host). Once this happens, ping your website – it’ll show you the IP address mapped to your domain name.

you should see your secondary server’s IP address. If you don’t, it’s because you recently visited your site and the entry was cached. You’ll just have to wait a maximum of 300 seconds (that TTL setting) for it to expire and your computer to make a new lookup. If your ping result doesn’t show a different IP address within 5 minutes, check over all the steps to make sure it’s been set up properly.

--------------------------------------------------------------------------------------------------------------------------------------------------------------

B))

Sometimes you will find a need to copy a website between two servers or upgrade hosting plan by switching to a brand new server or move to different hosting platform or may be sometimes moving to a complete different hosting provider. I have personally observed that the things go smoothly when we move a server or change the platform with the same host, but faced more trouble when switching from/to the different providers. Common mistakes happen if the source or destination host do not follow and do not execute some of these basic rules while doing the server/website migration.

Even though you sign up for a fully managed service and there is 24x4/7 supports to assist for the migration, you might face problems and inconvenience if you are not prepared enough and do not follow proper action plans. You have to provide all necessary information and updates to the local host, remote host and the domain registrar support teams whenever required to process smooth service and DNS transfer.

I have mostly worked on the Linux servers so will explain about all common types of the Linux servers migration. For windows hosting, the steps should remain same except data transfer and backup/restore procedure using windows control panel and other FTP/SCP utilities. This post should provide you guidelines and an action plan about which steps a server migration procedure needs to be followed to achieve successful migration. So here are some important points about migration that will help you to well prepare and have least problems during the switch over.

1. A new server setup and environment Settings

​​​​​​​If you get a new server or signup for a shared hosting account then make sure that the server environment settings match up with your application requirements. For the shared/Reseller account, the web host will not able to make any major environment change as other users sites are hosted on the same, so you should inform
host about your exact application requirement while processing signup and add a appropriate comment in your order.

If you are going to move on your own VPS or Dedicated Server then do mention appropriate requirements and also inform host about move while submitting an order. You should request support to check your existing server settings and ask to replicate as much as possible on the new server, so that there won’t be any compatibility issues after the actual server move. If you cant afford much downtime or change in the IP Address then ask support team if there is way to retain the IP address on new platform.

If possible, ask your host to use the same OS, control panel and also retain the same PHP, MySQL, Apache and other system and application services version and config settings. Very often due to Operating System's End of Life Policy [EOL] and also bugs and security vulnerabilities in the software version, its not possible to get the same release and hence we could not replicate the same environment settings as the old server. So you should consult with your developer/application provider and be prepare to re-design/update application to work on the new server environment.

You can refer to the following post which explains as what to do after purchasing your new VPS or Dedicated Server. This will help you to plan and configure your new server with better performance and security policies.

2. Notifying staff members and customers about the change.

As the website/server will be moved physically and/or there will be change in the IP Addresses and other DNS settings, there will be service downtime and hence inconvenience. So make sure that you schedule such events to weekend or midnight as there will be less visitors at that time. Also make sure that you host a separate portal on another remote server where you can post schedule maintenance and downtime updates about the server migration. It's recommended to put your sites in maintenance mode while migration is in progress and also when other maintenance task is going on that can affect live visitors. Keep your customers informed with the status posts/comments and also do send emails to your staff and customers so that they can also be prepared.

The most common causes of downtime during migration are, Propagation time due to change in the IP address and other DNS records, suspension of appropriate services to transfer all updates on new servers and the server or network service restart in some IP address routing case. You should be aware of all impacts due to these activity and notify end users about possible downtime for the same

3.Data transfer.

The main concern about the server migration is as how we are going to migrate the data and the configuration settings. The retention of the configuration settings and structure of all other contents as the emails, web data [ located in the home directory and Document Root], logs and statistics data and databases will depend on the backup format. There are smart features in most of the well known control panels like cPanel, Plesk to take a full/partial backup of your account/site and get it downloaded on the local machine or transfer it directly to the remote server.

As each control panel has different build structure and format and features support, we cant copy/move all the contents and the configuration settings same as they are across another server. Although some control panels support direct migration from their web panels, not all contents and the configuration settings are copied because of compatibility issues. In such scenarios, we have to copy contents manually and then need to update configuration settings accordingly.

So we do recommend to select the same control panel on the new servers and use standard full backup transfer method via SSH or control panel itself as much as possible. Our support team usually evaluates the server configuration and resources usage as soon as we receive migration requests and then will start migration with the right method with client's confirmation.We have to use control panel or SSH access with rsync, FTP/SFTP/SCP and wget utility to transfer the files and configuration settings between two servers. The transfer method will totally depend on the control panel support and size of the accounts and the server resources. For non compatible control panels and plain customized servers, we have to dump(export) the databases in .SQL/Data files and restore (import) on the remote server via phpMyAdmin or MySQL CLI tools. Regarding the files and directories data transfer, we have to make zip/tar archive and download it on the remote server via FTP/SFTP methods. If the server supports and allow access to SSH then use rsync tool to transfer data without creating zip/tar archive file as its very convenient and fast as compare to the FTP method.

Please note that most of the control panel uses different MTA (message transfer agent or mail transfer agent) and emails format, so we cant copy the email messages and email accounts across another server. In such cases, we can create email account manually on the new server and download all the messages via remote POP account option available in webmail plugins. If not supported by webmail then download all the emails on local machine via POP account configured under the suitable email client eg. Outlook/Windows Mail, Thunderbird.

If you feel need to change the domain or the user name and files/folders path then make sure that you update appropriate configuration files and reference in the database as well. Moving from different control panel and plain servers often cause file path issues. If the change is known and notable then we can easily replace it with replace utility from Linux shell or using rich text editor on any desktop OS. However, be prepared to face and troubleshoot URL and path issues due to the change in such environment settings. With the help of error logs and right trial and error method we can get it sorted out.

4.DNS records update.

The most inconvenience and interruption in the web service during website/server migration is faced due to the DNS change. We can reduce or avoid the propagation time completely by adopting proper DNS transfer method. Any time that DNS changes are made, we have to wait for propagation to complete due to cache update on the DNS server. So changes in the Name servers, IP address or any other DNS record takes time to resolve request from new server depending on the DNS servers located in different geographic locations. Its always suggested to use the same IP address and name servers records as much as possible. This will avoid downtime caused due to the DNS propagation. If its not possible to retain the IP Address then try to use the same name servers and just change their IP Address to point on new one server, so there wont be need to change other DNS records for all other domains on the new server.

In order to avoid downtime due to the IP address change, put new server's IP address in DNS zones of appropriate domains on old server and restart the DNS service. This will redirect traffic towards the new server and will avoid request coming on the old server.

Be prepared for any DNS records update and IP address change at your convenient time with the help of hosting and domain registrar support. The support is available 24-Hour so schedule change activity in the midnight or off-peak times so that there wont be disruption in any service.

5.Service suspension and final DATA sync.

As the DNS propagation takes a few minutes to 24 hours time and the resolution service totally depends on ISP's DNS server cache, some requests are forwarded to old server and the contents are served from the same server. To avoid any asynchronous update situation and get all the requests redirected to the new server,
disable/stop appropriate services on the old server and keep only DNS service running there to forward DNS request on new server till propagation happens.

The rsync is very useful utility software and network protocol in such asynchronous data communication situation due to the DNS change. We can sync only updated files and folders from old server to the new server during propagation time. So make sure that both the servers are accessible till the DNS fully propagate and we can run rsync again if required. Keep the old server active till 48 hours in case of you find need to compare data/settings or remigrate anything.

6.Ask for assistance.

We do take care of all migration things if the source and destination servers are hosted with us and client doesn't need to do anything from their end. Also if the client provides appropriate root/admin access credentials, we do provide all necessary assistance without any extra cost to migrate site/server from/to any external remote server. All of our managed servers include free technical support, so we insist clients to follow these rules with the help of our support team to avoid common mistakes in hosting migrations.

If you come across any issue or have a query about the server/site migration then just initiate a live chat session with our support team or open a helpdesk ticket and post your comment with the server login details. We will help you to get your server/site moved accordingly.