Most people add a second server for a good reason. A site became busier, a client needed its own space, or one box was overloaded. The second server resolves the problem in front of you. What it doesn’t always do is make anything safer, and adding a third one the same way just repeats the pattern.
If you run more than one server, these five questions will show where your setup is solid and where it’s just holding together by habit. Each one has a quick check you can run yourself and one thing worth doing this month. If you want to go deeper, each section links to a full guide.
1. Is your second server sharing the load, or just sharing the risk?
The most common two-server setup isn’t two servers working together. It’s sites are split across two boxes: some here, some there. That spreads the work, but every site still lives in exactly one place. If either server goes down, the sites on it go down with it.
Quick check: List every site and the server it runs on. Next to each, write what happens if that server goes offline for an hour. Then check where your backups live. If a backup sits on the same server it protects, it goes down with that server as well.
One thing to do: Pick your one site that can least afford downtime and write down how you’d bring it back if its server failed. If the answer is “restore from a backup and hope,” you’ve found your single point of failure.
Read the guide: Two Servers Isn’t Failover
2. Could your site run on two servers at once tomorrow?
Running one site on two servers at once, with traffic split between them, is how sites stay up when one machine has a rough day. But most sites can’t do it as they’re built today. A typical WordPress site keeps uploaded images on the server’s own disk, stores logged-in sessions locally, and expects one database. Put a second web server next to it, and visitors start seeing missing images and random logouts.
Quick check: Answer three questions. Where do your uploads live? Where are user sessions stored? Do all your web servers talk to the same database? If any answer is “on this one server,” a second web server won’t help yet.
One thing to do: Start with the uploads. Moving media to shared object storage is usually the first change that makes everything else possible, and it’s one you can make without rebuilding the site.
Read the guide: Object Storage for WordPress Uploads
3. Who can reach your database server right now?
When a database moves to its server, it has to accept connections over the network. The quickest way to get that working is often to open the database port and allow a list of IP addresses. It works, and then nobody touches it again. Over time, that list grows, and the port remains reachable from the internet.
Quick check: On your database server, run ss -tlnp | grep 3306. If you see 0.0.0.0:3306 or *:3306, MySQL is listening on every network interface, not just a private one. Then look at your firewall rules for port 3306 and ask whether you still recognize every address on the list.
One thing to do: Remove any allowed address you can’t name. If your servers can talk over a private network, move database traffic onto it and close the port to the public internet entirely.
Read the guide: Port 3306 Is Open
4. When you add a server, do its firewall rules come with it?
When each server has its own firewall, each one gets configured on a different day by whoever was there at the time. A port gets opened on one server to fix something and never closed. A rule is added to two servers, but the third one is left without it. None of this shows up until something gets through or something legitimate gets blocked.
Quick check: Export the firewall rules from each server and put them side by side. If you use iptables directly, iptables -S prints the full rule set. Any difference you can’t explain is drift.
One thing to do: Decide which rule set is correct and save it in one place, outside any single server. From now on, every server gets its rules from that file, and every change goes there first.
Read the guide: Firewall Drift
5. How long does it take you to add capacity today?
For most multi-server setups, adding capacity means ordering a server, waiting for it, installing everything, copying configuration from an existing one, and testing. That’s usually days of work, which is why it tends to happen after a slowdown instead of before one.
The faster way is a saved image: a ready-to-run copy of a server that’s already configured the way you want. Launching a new server from an image takes minutes, and every server you launch starts out identical, which also solves the drift problem from question 4.
Quick check: Time how long your last new server took, from the decision to add it to the moment it took real traffic. If it was more than a day, that’s how far behind you’ll be the next time traffic jumps.
One thing to do: Write down every step your last server build involved. That list is the first draft of the image you’d want to keep.
This is the kind of work InMotion Cloud handles for you. Your servers run as virtual machines on a fully managed private cloud, with fixed monthly pricing and senior engineers on every plan. See how InMotion Cloud works.
Read the guide: Server Snapshots vs Golden Images
When adding servers starts adding work
If this list turned up more to fix than you expected, you’re not behind. Most multi-server setups grow this way: one practical fix at a time. Work through the checks above at your own pace, starting with whichever one worried you most.
And if you’d rather your host owned more of this list, talk to our team about InMotion Cloud.