Some advice on set up

Voipy

New Member
Feb 5, 2026
23
0
1
56
I like the HA setup that is described in the manual and it seems easy enough. We currently have 3 FS servers and one central DB. We do this so that we can very easily spin up a new instance of Fusion/FS when one goes down, or if we need more capacity. It has run perfectly fine for years now.

If we make the switch to FSPBX we will do so slowly and put any new customers on FSPBX, and replicate manually each domain on Fusion, on FSBPBX so that we do not get any surprises if we'd import the DB and something not working - aside from the fact that my hope is that the FSPBX DB performs much better for tasks like call stats and CDRs - Fusion runs beautifully, except for those - they are unworkably slow, the GUI times out, etc. It just seems better to start with a clean slate despite it being a lot more work.

Any opinions on whether we should try and run FSPBX in a similar fashion with one DB and multiple FS instances? or Run one pair of HA servers - and if it start to get too busy, just have another pair? and move forward that way over time?
 
Last edited:
How about two central DB servers that are replicated against each other in two separate geographic regions, and then spin up as many PBX servers as you desire, that will either connect to centralized DB server A or centralized DB server B?
 
Hi

Yes if we go the central DB again, we would replicate it, but I am wondering if we don't make life a little more complicated that way and whether just having two different setups which would certainly suffice for now would not be the easier route. Then again, it would also mean two different sets of login details for clients, potentially causing confusion and headaches....
 
nothing wrong with going in that direction either. Maybe just have a primary and failover server. All traffic routes through the primary. Failover is only when there’s a problem or scheduled maintenance and you make dns change so that no one will ever need to know about the second login
 
I have many clients, small and large, that go with a primary-backup pair of servers. This way, both servers and databases are geographically redundant. You can always spin up new servers, add them to the cluster, and remove the old ones.

I like your idea of manually moving clients. Believe it or not, many did it the same way. Starting fresh always feels safer and eliminates the risk of old issues carrying over.