2 replies to this topic

[dominicsp]

Dear HR Members,

We have setup a new server with the same service provider.

The team is following the steps below and expecting a 8-10 hrs downtime. Any help woulf reduce the downtime would help

Step 1: Test and setup the site and related application in new server
Step 2: Switch off the existing server (so that we can take live data backup)
Step 3: Keep the under maintenance page on new server (new IP)
Step 4: During the downtime move the update-to-date data to new server
Step 5: Activate/Configure the applications in the new server
Step 6: Switch ON the site in new server (new IP will be assigned to site)

Will this have any impact on SEO and are they any ways to reduce the downtime

Regards
Domnic

[1dmf]

As long as the URL's and domain name hasn't changed, just the hosting server IP, it's a simple DNS name server change , that's it.

The only way to minimise downtime, would be to take the old site down, do the backup and restore to new machine as quick as possible.

Also remember any DNS changes could take up to 48 hours to fully propergate so ensure you set up a 302 redirect on the old server and leave it up (not the site, just the redirect), so you don't loose people as the DNS propergates.

Also as you can't have two sites with the same URL/Domain name on two diffrent boxes (IPs) , the redirect will have to be to IP, and ensure it's a 302, so when the old box comes down, G! hasn't reindexed your site with IP, instead of domain name!

[Randy]

It's not going to have some massive effect on your SEO one way or another since you're only talking about there being a bit of confusion for a few hours. The spiders will simply revisit if they find things gone.

That said, you didn't mention anywhere in your sequence list where the DNS switch is happening. And you'll want that to happen ASAP in the process since it takes the longest to complete. So I'd have that right up there in first position and simply make sure I use the IP number to make sure I was connecting to the correct server.

How to best handle the DNS depends upon how it's being done now. If you have to change nameservers in the domain registration entirely expect things to take a little longer to propagate. Whereas if the nameservers in the domain registration is remaining the same and you control the nameserver domain(s) too you can effectively speed up the propagation by changing things at the local server level.

Long story short, give some considered thought to what you're going to do with the DNS. That's what is going to control how smoothly things go for everyone else.

As to the rest, I gather from your original post that there is a capability on the site that allows users to add content? I'm making an assumption here, but it's the only thing that makes sense in the data snapshot part of the equation. Because if you are the one adding/changing data simply plan not to add or change anything for a day or two while the server switch is happening.

There are three basic ways to handle server moves on domains where users can add content. One is as you've laid it out.

A second way that causes the least amount of downtime of this capability, assuming we're talking about a typical MySQL database (or equivalent) database setup is to:

1. Move your db snapshot to the new server.
2. Open up your firewall on the new server temporarily to allow external db connections from the old server.
3. Change the db connection information on the old server apps so that they point to the IP number of the new server, instead of pointing to localhost.

This assumes actual files aren't changing, just database entries. But by moving the db connection off to the new server it won't really matter if users are connecting to the old server or new server, because both with be using the same database. The one located on the new server.

The third way is to leave the db connection routine the same on the old server, but disable data entry for users on the old server, giving them an friendly error message to tell them what's happening during propagation. Set everything up on the new server to work normally. This will mean that some users will not be able to enter, add or change data while their individual propagation takes place. But once the DNS propagation has occurred for each user the system will work for them again.

The big advantages of the 2nd and 3rd option is that the site never actually has any downtime for the search engine spiders and/or most users. It's all still there, no matter which server they're connecting to. Just that users ability to alter data may be limited for a short time.

With any of these though the major issue is going to be the DNS propagation. As 1DMF said, this process can take some time. As a general rule it'll take 24-48 hours. The closer you can get the DNS changes to the local server the better. On my own sites, where I have complete control of the DNS at the server level, I've found I can trigger DNS propagation very quickly. Literally forcing it to happen immediately for folks who haven't visited the site before or recently. The only users who have to wait even 24 hours are those who have the old DNS info on their local PC because they've visited the site recently.

Long story short, as long as you manage the DNS propagation well you can expect little or no down time. So it's important to make this a major part of your thought process.