Painless way to migrate server?

Question

I'm a very newbie server admin. I am running a pretty basic cloud server (Windows 2008 R2), which is hosting a couple of different public web sites. The services and database have now grown a lot, and my server is dying under the load. So I contacted the cloud hosting company and apparently the type of server I took out, being the cheapest I could find at the time, cannot be upgraded - not even the memory! - and I now need to get a new server.

So now I have a couple of issues:

1. Several DNS records are pointing to the old server.
2. The web sites are interacting with a SQL Server instance on that server, so I need to freeze the web sites before I can backup and restore the DB on the other server.

I want to migrate my SQL Server and DNS records to the new server, with minimum downtime and disruption to the website users.

I know I'm not the first person in the world to have to go through this exercise, so I'm hoping some more experienced people out there can give me some tips how to minimize the pain.

Thanks!

Answer 1

With DNS you'd need to set the TTL low so the transfer will take effect faster when you change them over.

I'd get a new hosting company and begin replicating the software configuration on the new system as much as possible. Static content would be the simple to move.

Hard part is the dynamic content, like what's in the database server. Get a dump of the data from the SQL server then import it into the new servers. This should give you a fairly up-to-date version of the website to get running in parallel with the production system.

Once you've confirmed that everything is working in the new site, "lock" the old one by disabling access and dumping the database, then re-import data to the new site, re-point the DNS, and go live.

Of course you'll need to work with the site owners of the sites you're hosting so you can place announcements about the move for their users. You can even put in a redirect page on the old site to redirect to the new site once you have it up and running until the DNS migration takes effect.

Once the DNS is fully migrated shut down the old server. Wait a couple of days, then shut down permanently with the old provider.

For large sites you would look at strategies for running in parallel for awhile; replicating SQL servers across network connections and blah until you can shut down the alpha site and bring up the beta (secondary) site, kind of like disaster planning with two data centers and simulating a shutdown of your primary site. If you're a small operation as it sounds like you are, you're going to end up having to create a parallel install, then when the kinks are worked out you take down the primary and bring up the secondary and wait for DNS to work its magic, helping it with an automatic redirect of your old site. You'll want to warn that there could be a day of maintenance/outage, although the cutover itself should only take a few hours if you set the TTL low ahead of time. Just factor in some fudge factor-uh-oh time.

And check your logs to tell you when the best time to cut over is, with minimal use. Even my bank warns that their service will be unavailable during hours in the middle of the night into Sundays...even though I have yet to see it actually completely dead from access.

Answer 2

Couple of steps

• DNS Records - reduce the TTL first, let that propagate at least 12 hours. IF you have a good DNS provider, they will happily assist. This way if you change records which you intend to, it will update according to TTL. BUT remember it can take up to 48 hours for global DNS servers to update.

• You really should be separating database services and File Services/printing/AD. Consider virtualisation or separate servers if feasible.

• You may take backup even when the website is 'live'. But obviously you want the latest backup to restore. Therefore i suggest you do a 'test' to ensure the restore works, and a live at the time of going 'live'. You may consider a 'locking mechanism' to prevent any writes occurring but you'd want to do this at the least busiest time (unfortunately that is usually out of standard working hours).

• As for the website, you need to be running side by side, ensure the website is accessible locally with the test database. Otherwise you may find that you run out of time to troubleshoot any 'potential' issues that could/have easily occur. For testing you do not need to change DNS but rather go on IP addresses.

Answer 3

Timing

...so I need to freeze the web sites...

Is that actually an option? If so, you're a lucky duckling! If it's not truly an option, you're going to want to figure out when your websites are least frequently used, and perform your migration then. For me, this is usually a Saturday night (what some people call a "change window") and running into Sunday morning.

Techno Babble

DNS

Who did you purchase your domain through? Who is doing managing the DNS records for you? Updating the DNS for your site should be pretty painless. Just use the tools (most likely some webpage) that your provider has for updating the record. But, beware, it may take a few minutes or a few hours for the entry to full propagate. To help alleviate this time, you can lower the TTL.

SQL

Backing up your SQL Server database should also be fairly painless. Inside of SQL Server Management Studio there are tools that will backup the database for you.

Future

Separate your database server from your web server. Either through different physical boxes, or virtualization. Anytime you need to move a server, you don't want to have to move everything.