Conceptually, you need only one server. In practice, for scalability, you may want to split this "one server" in many server processes, possibly on different machines, to distribute load... but that need is far into the future and you should worry about it when you get there. Not now.
So, what you need is one server. That server, in the context of your question, will have two jobs:
- to transmit updates to the game state to all connected clients
- to replicate the current game state entirely to any newly-connecting clients
That means that as the server gets requests from clients and processes them, it updates the game state and tells any clients about those updates (if it matters to the client).
Similarly, when a new client connects, the server sends it information about whatever the current state of the game is, at least as far as what matters to the client. It's quite possible for one logical server to do and in fact it is somewhat easier to work with as that one server has all the state, makes all the decisions, and knows about all the clients. That means there is no server-to-server state replication to worry about, no additional layer of complexity introduced by run N copies of the game on the server for N clients, like you were suggesting in your question.
Just use one server, have it sends relevant updates to connected clients, and relevant complete state for new clients.
(I keep saying "relevant" and "what matters to the client" because you only want to tell the client about things it should know about; don't tell it about things that it can't yet see, for example, because that enables client-side "map hacks" and the like.)
