Two Servers Isn't Failover: What Real Failover Needs

Most people add a second server for a good reason. A site got busier, a client needed its own space, or one machine was overloaded. The second server fixed that problem. It did not give you failover, and it is worth being clear about the difference before your busiest weeks of the year.

Failover means that when one server stops, another one carries on serving the same site, ideally without anyone noticing. Two servers with different sites on each is a sensible way to share the work. Each site still lives in exactly one place. This guide explains what real failover needs, how to test whether you have it, and where to start. The glossary entries on high availability and the load balancer cover the terms.

Split is not the same as redundant

The most common multi-server setup looks like this: some sites on server A, some on server B, maybe a database on one of them. It is tidy, and it works well on a normal day.

If server A has a hardware fault or a kernel panic, every site on server A goes offline until it is fixed or restored. Server B keeps running its own sites, but it cannot pick up A's work, because nothing on it knows how to serve those sites.

That setup halves the number of sites affected by any one failure. It does not reduce the chance that a given site goes down.

Comparison of sites split across two servers, where a failed server takes its sites offline, and a redundant setup where a load balancer sends traffic to the surviving server. — Failover needs another server that can serve the same site and routing that avoids the failed instance.

What real failover needs

For one site to survive one server failing, four things have to be true.

Two or more servers that can each serve the site on their own. Same code, same configuration, either one able to handle the traffic by itself, or at least enough to stay up.

Something in front that routes around failure. Usually a load balancer that checks each server's health every few seconds and stops sending traffic to one that fails. DNS-based failover also exists, but cached DNS answers can keep sending visitors to the dead server for minutes or longer.

Shared data. Both servers need the same uploaded files and the same database. If uploads sit on one server's disk, the other one serves broken images. Our guide to object storage for WordPress uploads covers the usual first fix.

A database that is not the weak point. If both web servers depend on one database server, the database is now your single point of failure. That may be an acceptable risk to start with, but it is worth naming.

The quick check

List every site and the server it runs on. Next to each one, write what happens if that server goes offline for an hour: who notices, what it costs and how you would bring it back.

Then check where your backups live. If a site's backup is on the same server as the site, it goes offline with that server too, which turns an hour's outage into a much longer one. We wrote more about where your backups live and why it matters.

Example worksheet listing each site, its server, the impact of an hour's outage and where its backup lives, with backups on the same server flagged in red. — Map each site's outage impact and check whether its backup could fail with the server.

If moving to infrastructure where adding and replacing servers takes minutes is on your list, our pricing page shows what each InMotion Cloud Virtual Private Cloud plan includes.

One thing to do this month

Pick the one site that can least afford downtime, usually the shop or the client-facing app. Write down, step by step, how you would bring it back if its server failed tonight.

If the honest answer is "restore from a backup and hope", you have found your single point of failure. That is the site to make redundant first. Everything else can wait until that one works.

Making one site redundant, in order

You do not need to rebuild everything at once. For a typical web application, the order that causes the least disruption is:

Move uploads off the server to shared storage, so any server can serve any file.
Check session handling. Core WordPress keeps login tokens in the database, so logins work across servers as long as every server has identical security keys in wp-config.php. Plugins that store PHP sessions on disk need a shared session store.
Move the database to its own server, reachable over a private network from both web servers.
Add the second web server with identical code and configuration.
Put a load balancer in front with health checks.
Test it. Stop one web server on purpose during a quiet hour and watch the site stay up.

The last step is the one people skip. Failover that has never been tested is a hope, not a plan.

Six-step sequence for making one website redundant, from moving uploads to shared storage through to testing failover by stopping a server. — Prepare shared state and routing, then prove the setup by stopping one web server during a controlled test.

How InMotion Cloud handles this

On InMotion Cloud, your servers run as virtual machines on a private environment, so adding a second web server is a matter of minutes rather than an order and a wait. Load balancers with health checks are part of the platform, and server groups with anti-affinity rules keep the copies of a site on separate physical hosts, so one hardware failure cannot take out both. Our overview of high availability options shows how the pieces fit.

What it does not do is make your application redundant automatically. Uploads, sessions and the database still need the changes above. Our engineers can help you plan and make them.

Summary

Two servers with different sites on each shares the work, not the risk. Real failover needs at least two servers that can each serve the site, something in front that routes around failure, shared data and a plan for the database. Start with your most important site, make it redundant step by step, and test it by switching a server off.

Want your most important site to survive a server failure?

InMotion Cloud engineers will look at how it runs today and map the steps to make it redundant.

Talk to a cloud architect

Frequently asked questions

Is having two servers the same as failover? No. Failover means another server can take over the same site when one fails. Two servers running different sites only limits how many sites one failure affects.

Do I need a load balancer for failover? Usually. A load balancer checks server health and stops sending traffic to a failed server within seconds. DNS failover is slower because of caching.

Why does my site break when I add a second web server? Usually because uploads or sessions live on the first server's disk, or because the servers have different configuration or security keys.

How do I test failover? During a quiet period, stop one server on purpose and confirm the site keeps working. Then bring it back and check it rejoins cleanly.