Skip to main content

Primary–Standby FS PBX (HA) — Overview

This guide covers a two-node Primary–Standby design for FS PBX with:

  • Database: PostgreSQL logical replication (bi-directional)
  • Files: Syncthing folder replication (bi-directional)
  • Failover: A floating DNS name (e.g. pbx.example.com) that points to the active node
  • Nodes: Two individual A/AAAA records (e.g. server1.example.com, server2.example.com) used for direct access and peer-to-peer replication

Goal: If the primary fails, the standby already has fresh DB + files and can take over in minutes with a DNS switch (or an automated health probe).

DNS Model​

  • server1.example.com → Node A (Primary)
  • server2.example.com → Node B (Standby)
  • pbx.example.com → Floating DNS record that points at the active node (A or B)

You can update the floating record using:

  • A provider API (Route53, Cloudflare)
  • A lightweight health probe/cron that flips to the healthy node
  • (Optional) very low TTL (e.g., 30–60s) for faster cutover

Traffic & Data Flows​

  • SIP/RTP: Flows to the active node (via pbx.example.com.
  • API/UI: Users hit the floating name; web sessions and API calls reach the active node.
  • Database: Logical replication both ways; initial copy runs A → B, then continuous bi-directional replication.
  • Files: Syncthing mirrors recordings, voicemails, storage, and sounds across both nodes.

Why Syncthing + Logical Replication?​

  • PostgreSQL Logical Replication: Granular, resilient, faster bootstrap; easy to control origin and copy-data semantics. Works well for PBX metadata, queues, and live tables.
  • Syncthing: Efficient delta sync for large media trees (recordings/voicemail), resilient to interruptions, auto-recovers, and handles lots of small files gracefully.

Prerequisites​

  • Both servers with FS PBX installed.
  • SSH key-based auth configured both directions (A⇄B).
  • Open firewall: TCP 22 (SSH), TCP 5432 (Postgres between peers).
  • External or internal IPs are fine; as long as servers are able to communicate.

Implementation Sequence​

  1. Prepare DNS records for server1, server2, and pbx.
  2. Set up Postgres replication (bi-directional). See: Bi-Directional PostgreSQL Setup.
  3. Set up Syncthing with the FS PBX folders. See: Syncthing File Replication.
  4. Point your floating DNS (pbx.example.com) at the active node.
  5. (Optional) Automate failover with a health probe + provider API.
  • Fast cutover (DNS flip), minimal data loss
  • Keeps media and DB continuously in sync
  • Works with public or private (internal) IPs

Operational Notes​

  • Apply FS PBX updates on the primary first, verify, then the standby.
  • For emergency failover: update floating DNS → verify registrations → monitor calls.

Nginx certificate​

Use one Nginx certificate containing the floating hostname and both direct node hostnames. Run the FS PBX Let's Encrypt installer on the active node and select Redundant server pair. The installer publishes HTTP-01 challenges on both nodes, installs the same certificate on both, and makes renewal ownership follow the floating DNS record.

Do not request a separate certificate containing the floating hostname on each node: the floating hostname reaches only the active node during validation. Follow the complete Nginx Let's Encrypt certificate guide.