Standby Server

A standby server gives an All-in-One server a second server that stands ready to take over if the first one stops working. The second server keeps its own copy of your data, kept current as changes are made, so when you switch to it, it can start answering calls straight away.

Two things to know before reading further:

Call recordings are not copied and need their own arrangement. See Where call recordings should live.
Switching over is one-way. The role never returns to the original machine - see After a promotion.
This is not the only arrangement. Some sites run an HA cluster instead - two servers sharing a mirrored disk, built for them by the Thirdlane services team. The two must not both manage the same data, so on a server that already has a cluster this screen refuses to pair a standby and points you at the HA Cluster screen, which is where the mirror is reported.

Navigate to General Settings & Tools > Standby Server to set up the pair and to check whether a switchover would actually work.

Why you may want it

On a single server, anything that takes the machine out of service - a failed disk, a power or hardware fault, a data center problem - stops all calls until you either repair the machine or install a replacement and restore a backup onto it. Restoring a backup is measured in hours, and you lose whatever happened after the backup was taken. With a second server already running and already holding a current copy of your data, there is no hardware to source and no backup to restore, so service returns in minutes.

A standby server protects against losing a server. It is not a backup, and it does not protect against mistakes - a configuration error or an accidental deletion is copied to the second server like any other change. Keep taking backups.

How it works

You run two servers as a pair:

The active server does all the work. It handles calls, serves Configuration Manager, and is the one your phones and users are connected to.
The standby server receives a continuous copy of the active server’s data but does not answer calls. It is deliberately blocked from starting the services that answer clients - telephony, Thirdlane Connect and messaging - so the two servers can never both try to run the same phone system. Its Manager and its Update Manager stay available, which is how it is administered and promoted.

A consequence worth knowing before you test it: a Connect client or a phone pointed at the standby’s own host name gets an error rather than a working session, because the services behind it are stopped on purpose. Clients reach the pair through the service name, which always points at the active server.

Data reaches the standby two ways, and both need to be working for it to be current: database replication carries configuration and call records, and MongoDB replication carries chat history, voicemail, and the audio your tenants uploaded. The standby also rebuilds its own telephony configuration from that data as it arrives, and restores tenant audio and voicemail to local disk. This is what removes the restore step - the standby is not holding a backup file waiting to be unpacked, it is holding a copy that is kept current.

When the active server fails, you switch over by promoting the standby. Promotion is something you do; the system never does it on its own, because two servers on their own cannot reliably tell “the other server is down” apart from “I cannot currently reach the other server”, and a server allowed to promote itself during a brief network problem would leave you with two servers both answering calls and both accepting changes.

What is replicated

Data	Reaches the standby
Configuration (tenants, extensions, routing, trunks)	Yes, by database replication
Call detail records	Yes, by database replication
Chat history and attachments	Yes, by MongoDB replication
Chat sign-in credentials, contact lists and group chat rooms	Yes, captured as configuration
Tenant hold music and greetings	Yes, by MongoDB replication
Voicemail messages and greetings	Yes, by MongoDB replication
Call recordings	No - see Where call recordings should live

Recordings are excluded because of their volume: every one would be written a second time through the replication log, and at that rate the log stops being large enough to let the chat data catch up after a brief interruption. Shipped product audio - the standard system prompts - is reinstalled with the software rather than being customer data, and chat presence, meaning who is shown online, describes a moment that has passed by the time it would arrive.

Voicemail on a pair

Voicemail is copied to the standby automatically, on by default, with nothing to configure. What travels: the messages in every folder of every mailbox, together with the recording that goes with each one; the greetings a caller hears; and the recordings held in each mailbox’s greeting library. Deletions travel too, because a copy left behind on the standby would reappear as a duplicate message once that server took over.

The copy runs every five minutes, and that is the size of the gap. If the active server fails, messages left in the last few minutes are on that server and only on that server, and they cannot be moved across afterwards - Asterisk numbers the messages in a mailbox in sequence, and the promoted server has been numbering its own from the moment it took over. The message-waiting indicator needs no copying: Asterisk works out the count by reading the mailbox, so the promoted server produces it from the messages it now holds.

If voicemail is a large share of your storage. Every copied file also passes through the replication log. The Voicemail copied to standby readiness line reports how much has been copied and warns when it grows past a level worth reviewing. Two ways to reduce it: lower the number of messages a mailbox keeps, or stop copying voicemail by creating this file on the active server:

touch /etc/webmin/asterisk/redundancy.novoicemail

Creating it stops the copying and clears what has already been copied, on both servers. Remove the file to start again. Readiness reports plainly when voicemail copying is off.

A standby is expected to be a newly deployed server. If you paired a server that had been carrying calls before, the voicemail from that earlier service is still on its disk, and pairing does not delete it. It stays invisible until a promotion, at which point it appears in mailboxes beside the copied messages. Readiness reports how many files are in that position so you can remove them or redeploy the server.

Where call recordings should live

Recordings are the one kind of customer data the pair does not copy, so they need an arrangement of their own, and object storage is worth understanding even if you are not running a redundant pair.

What it is. A service that holds files and hands them back by name over HTTPS - Amazon S3 is the original, and there are several compatible services as well as ones you can run yourself. It is not a disk and not a file share: nothing mounts it, the platform uploads and downloads over the network, and its capacity is unrelated to the size of any server’s disk.

Why recordings suit it. A recording is written once, listened to rarely, and kept for years, because a regulator or a customer contract says so. Local disk is the resource a PBX runs out of first, it grows in a way nobody predicts accurately, and enlarging it means an outage. Move recordings to object storage and the PBX only ever holds the last day of them, capacity stops being something to plan, and the storage service keeps multiple copies, which no single disk does. For a pair, both servers are configured with the same bucket, so a promotion loses only the recordings of the last few minutes that had not been uploaded yet.

Configured on the File Storage tab: a call is recorded to local disk as usual, and every five minutes recordings at least two minutes old are uploaded. The local copy is kept for 24 hours by default, then removed, and playing an older recording fetches it from storage. A network file share both servers mount solves the same problem and is supported on the same tab.

If you keep recordings on local disk instead, they stay on the server that recorded them, so after a promotion everything recorded before the switch is on the parked server - still readable there, but not reachable through the promoted one. The divergence report written at promotion counts those files. See File Storage for the settings and the supported services.

The three names

Your phones, Connect clients, carriers and webhooks are all configured with a name for your system. If that name points at one specific machine, promoting the other machine achieves nothing - everything still tries to reach the server that failed. So a pair uses a name that belongs to neither machine. Suppose your two servers are pbx1.example.com and pbx2.example.com, and your phones are configured to use pbx.example.com:

Name	Points at	Used by
`pbx1.example.com`	The first server, always	Administrators, replication
`pbx2.example.com`	The second server, always	Administrators, replication
`pbx.example.com`	Whichever server is active right now	Phones, Connect, carriers, webhooks

The first two are server names: each belongs to a machine and never moves. The third is the service name, which belongs to the pair rather than to a machine and moves when you promote. It has to be a name of its own - setting it to pbx1.example.com is accepted by the form and then reported as a failing check, because that name is the first server’s own and cannot be pointed at the second server.

The readiness checks refer to a server name as a node name. It means the same thing.

Moving the service name

The service name has to reach whichever server is active. Moving it is a step in the switchover, and it is the part most often misconfigured.

There are three methods. What separates them is who moves the name, and whether the platform can confirm it moved.

DNS (dns) - the platform changes a DNS record during the promotion, then confirms the name answers with the new address. It does not depend on how your addresses are managed, so it works wherever the two servers are. Cloudflare, PowerDNS and DNS servers that accept standard updates are handled directly; anything else needs a script you supply.
Floating IP (vip) - the platform adds an additional address to a network interface on the promoted server and announces it locally. Whether that is enough to redirect traffic depends on how addresses are managed where your servers run, so check before choosing it. On a network you administer yourself, a machine can take over an address this way. Where the network belongs to a cloud or hosting provider, an address is normally assigned to a machine by the provider and moved through the provider’s own facilities, which a server cannot do from the inside - in that case use DNS, or let the provider’s own mechanism move the address and record the method as external. This is the form’s initial selection.
Moved outside Thirdlane (external) - the platform does not move the name and does not check that it moved. Choose it when something else owns the name or the address: a load balancer, a provider’s own failover facility, or an operations team following a runbook. A promotion completes and reports success whether or not the name followed, because nothing in the platform is in a position to notice.

Whichever you choose, the Move method check on the Standby Server screen reports what is configured, and when something is missing it states the exact action to take.

Floating IP

You supply two values: the Floating IP address itself, and the Interface that should carry it, for example eth0. Readiness verifies that the interface exists and reports which server currently holds the address. On promotion the address is added to that interface and announced on the local network so that switches and phones stop sending traffic to the previous holder; when a server gives up the role, it removes the address.

DNS

With DNS, the service name stays a normal DNS name and the record is changed to point at the newly promoted server.

The cost is that DNS answers are cached. A client is told both the address and how long it may reuse that answer - the record’s TTL (time to live) - and keeps using the address it already has until that expires. So set a short TTL on the service name, 30 to 60 seconds is typical, well before you need a switchover: lowering a TTL is itself subject to the old TTL, so shortening it during an outage does not take effect in time to help.

The DNS hosted by setting says who makes the change. Three cases are handled directly, with nothing to write and nothing to install on either server:

Cloudflare - Domain (for example example.com, and the service name has to sit inside it), Cloudflare Zone ID from the overview page for your domain, and an API token created with the Edit zone DNS template scoped to that domain. The Zone ID is asked for because a token restricted to editing DNS cannot look a domain up by name, so you can issue a narrow token instead of a broad one.
PowerDNS - Domain, the PowerDNS API address such as http://ns1.example.com:8081, the server ID (localhost on a standard installation), and the value of the api-key setting as the API token. That API port is not the port that answers ordinary DNS questions; it is normally 8081, closed by default, and both servers have to reach it, so a firewall rule is usually needed. Without it the connection fails with “no route to host”, which reads like a broken network when the network is fine.
BIND or another DNS server that accepts standard updates - a change sent straight to the server as an ordinary DNS message, rather than through a website or control panel. This is a standard part of DNS rather than one company’s feature, so one setting covers BIND, Knot, NSD and Windows DNS, and some hosting companies accept it as well. You are not giving the platform an account login: whoever runs the DNS server creates a key with permission to change one record and nothing else. Enter the Domain, the DNS server to update (the machine holding the editable copy, which is often not one of the servers listed publicly for your domain), the Key name exactly as created, the Key algorithm (usually hmac-sha256), and the key’s secret as the API token. On BIND the key is made with tsig-keygen and granted with an allow-update or update-policy line - ask for permission on the service name alone.

Not handled directly: Amazon Route 53, Azure DNS and Google Cloud DNS. Each proves who you are in a different way, so each would have to be built in separately. For these, and for any hosting company not listed above, use the script described below - but ask your hosting company first whether they accept changes sent straight to the server, because several do without advertising it.

These details are entered once, on the active server. They are stored encrypted and reach the standby with the database copy.

Check it before you rely on it. Once a provider is chosen, a Test DNS Connection button appears under the fields. It contacts your DNS with the values on screen and reports what came back, changing nothing. The same check runs as part of readiness, which is what catches a token that has been withdrawn or has expired.

During a promotion, the promoted server changes the record to its own address, then asks the servers holding your domain directly - rather than by an ordinary lookup, which could be answered from a saved copy - until they answer with that address. A provider that refuses the change is reported as a failed step. A change accepted but not confirmed within thirty seconds is reported as done but unconfirmed, because by then the record has been written and stopping would leave the pair worse off.

Any other DNS provider: you supply a script

Set DNS hosted by to Another provider - I supply a script and install a script at /etc/webmin/asterisk/redundancy-dns-hook on both servers. A commented template ships with the platform:

cd /usr/libexec/webmin/asterisk/config_adm/bin
cp redundancy-dns-hook.sample /etc/webmin/asterisk/redundancy-dns-hook
chmod 755 /etc/webmin/asterisk/redundancy-dns-hook

The platform calls it with the service name and, when claiming, the TTL:

redundancy-dns-hook claim pbx.example.com 60
redundancy-dns-hook release pbx.example.com

claim must point the service name at the server running the script; release must stop pointing it there. Exit 0 for success and non-zero for failure. The result is confirmed the same way as for the three providers above, so a script that exits successfully without having done anything is reported as unconfirmed rather than believed.

Readiness confirms only that the file exists and can be run, because the one way to find out whether a script works is to run it, and running it changes your DNS. Test it by hand first, and expect dig +short pbx.example.com to answer with the address of the server you ran it on. The unedited template deliberately exits non-zero, so an incomplete installation shows up as a failed step rather than as a promotion that believes the name moved. Because the script lives outside the platform’s own files, an update will not overwrite it - and will not repair it either. Scope its credentials as narrowly as your provider allows.

Setting up

Setting up a pair happens in two stages, and they are deliberately separate. Recording is deciding which server is which: it writes down the roles, the name of the other server, the shared service name and how that name moves. It stops nothing, changes no setting and starts no replication, so it can be reviewed and corrected freely. Pairing is doing something about it, and it is the stage that turns on replication and stops the standby answering calls.

Recommended: have your provider set this up. The steps below are complete and you can work through them yourself. A pair also touches database replication, certificates, the service name, and every integration that has a hostname stored in it, and it is only proven once a failover has been tested end to end. Your provider offers the setup and that test as a professional services engagement.

Everything pairing changes lands on the standby, and nothing in the platform can execute on the other server, so each stage is run on the machine being changed. The order is fixed: prepare the active server first, because the standby copies from it.

Step 1 - record what each server is

On the server that will be active, open General Settings & Tools > Standby Server and click Configure. Choose Active, then enter the Other server (pbx2.example.com), the Service name (pbx.example.com), and how that name moves along with the values the chosen method needs.

Saving validates what can be checked without touching anything: that the other server is not this one, that its name resolves, that the service name is not either server’s hostname, and that any interface named exists. Problems are listed together, with the fix for each.

Then do the same on the standby, where the form asks only two things: choose Standby and enter pbx1.example.com. It does not ask for the service name or the move method, because those belong to the pair and arrive with the database copy during pairing.

Until pairing runs, both servers keep behaving exactly as they did before - including the one recorded as the standby, which is still carrying calls normally.

Step 2 - pair the active server

Still on the active server, click Set Up Pairing, then Check and Show Plan to see the steps without applying them. When you are satisfied, click Set Up Pairing. Calls are not interrupted; the database restarts briefly, which is what puts binary logging into effect.

When it finishes it prints a replication password. It is shown once and stored nowhere - copy it now. If it is lost, run this step again to set a new one.

Step 3 - pair the standby

On the standby, click Set Up Pairing, enter the replication password from the previous step, and click Check and Show Plan first. The check contacts the active server and reports whether it answers, whether the replication account works, whether binary logging is on, and how much data would be copied. It changes nothing on either server, so if something is wrong this is where you find out - not after the standby has stopped answering calls.

When the check is clean, click Set Up Pairing and confirm. This stops telephony on this server, replaces its databases with the active server’s copy, and starts replication. It takes a few minutes and must not be interrupted.

Pairing from the screen is offered only while the data to be copied is small, under 100 MB of configuration and call history, and above that the check reports the measured size and stops. That is a limit on doing the copy from a browser rather than a limit on the pair: a server carrying a year of calls is a longer job than a web request should own, and one where a mistake costs a restore rather than a retry, so it is work for your provider. Chat history is reported alongside but does not stop pairing, because MongoDB makes that copy itself in the background once the standby joins. Both thresholds can be adjusted through the redundancy_seed_max_sql_mb and redundancy_seed_max_mongo_mb system settings.

Chat history and file attachments are in MongoDB, so pairing starts a replica set on the active server and adds the standby to it, and MongoDB then copies the existing history across by itself. That continues in the background after pairing reports success, so a large history means the standby is complete some minutes later, not that pairing failed.

Chat sign-in credentials, contact lists and group chat rooms are held by the chat server in files rather than in a database, and cannot be recreated from the Manager’s copy of a password. They are captured on the active server, carried by ordinary replication, and written back out on the standby - together, because a server with the history but not the rooms has the conversation and no way to open it.

Readiness reports four chat checks separately, and none of them blocks a promotion, because a server that cannot do chat can still carry calls. They do tell you what a promotion will and will not restore.

After pairing, configuration is made on the active server

Once the two servers are paired, the standby’s Manager stops accepting configuration changes. Every screen still opens and still shows the current settings, and reports and diagnostics work as before, but saving a change is refused, with a message naming the server to make it on. A change saved on the standby would either be overwritten the next time that record arrives from the active server, or survive and leave the two servers holding different ideas of how the system is configured - and the second is worse, because nothing reveals it until the standby is promoted.

Three things stay available on the standby, because they are about that machine rather than about the pair: Tools > Update Manager, since each server installs its own software; Licensing, since each server registers separately; and the Standby Server screen itself, including Promote to Active.

The REST API is treated the same way. A read is answered normally; a request that creates, changes or deletes something is refused with status 409 and the same explanation. Point API clients at the service name rather than at either server’s own name, and they follow the active server across a failover.

After pairing, the redundancy configuration is read only

Configure still opens and still shows what the pair was set up as, but nothing in it can be changed - on the active server as well as on the standby. The configuration now describes two machines, and editing one server’s copy of it only makes the screen disagree with the servers that are running.

To allow one change, create /etc/webmin/asterisk/redundancy.unlock on the server. The next save consumes it and deletes it, so it cannot be left behind by accident.

Doing it from a shell instead

Every step above is the same script the screen runs, and it can be run directly:

/usr/libexec/webmin/asterisk/config_adm/bin/deploy_redundancy.pl --help
/usr/libexec/webmin/asterisk/config_adm/bin/deploy_redundancy.pl --status

--declare records, --pair applies, and --plan added to either prints the steps and changes nothing. A shell is the only way to pair a server whose data is above the size limits, and to use --include-certificate to capture the TLS private key. --reconcile re-applies the settings of a pair that already exists; it is a repair tool rather than part of setup, and it is not offered in the browser because on a standby it fences the server.

TLS certificates

The standby serves the same service name as the active server, so it needs the same certificate. Either use --include-certificate, which copies the keypair into a replicated table so a promoted standby has it automatically, at the cost of the private key existing in the database and travelling with replication; or issue independently on each server using a DNS-01 challenge, so each holds its own certificate for the shared name and no key is replicated.

Readiness reports whether the standby has a usable certificate either way. A missing certificate is the most common reason a technically successful promotion still fails to carry calls.

The service name has to be a SIP domain as well

Phones are given the service name, so it is what appears as the domain in the SIP messages they send. The call proxy only answers for names it has been told are its own, and refuses anything else with 403 Not relaying before any password is looked at - so every phone on the pair would fail to register, on both servers, which reads as a network or credential fault and is neither.

This is done for you. Saving the redundancy configuration writes the service name into the list of names the proxy answers for, and deploy_redundancy.pl --reconcile --role=active writes it too, which is how a pair set up before this existed picks it up. On the standby the same file is rewritten on a schedule, so the name is in place before it is promoted. Readiness reports the result as Phones can register to the service name.

Two things it does not do: it does not put the name on the certificate, which is the separate Certificate covers service name check, and it does not cover encrypted SIP - if phones reach the pair over encrypted SIP, the certificate the proxy presents has to cover the service name as well, which is set on SIP Encryption (TLS).

Bookmark the standby now

The service name always points at the active server, which during an outage is the server that failed, so this screen will not load through it. To promote the standby you must reach Configuration Manager on the standby’s own server name. Bookmark that address while everything is still working.

Checking readiness

The Standby Server screen shows a diagram of the pair, whether the other server is answering, and the readiness checks with a list of actions for any that are failing. A check that cannot be evaluated is reported as failed rather than passed, so an unknown result is never mistaken for a working one. Refresh re-runs them.

The checks that most often need attention:

Service name - that it is set and is not one of the two server names.
Move method - for a floating IP, that an address and interface are set and the interface exists. For DNS with a provider selected, a live call to that provider, so a revoked or expired token shows up here rather than during a promotion. For DNS with a script, that the script is installed and executable. With external, there is nothing here to check.
Floating IP announcement - that the arping tool is present, which is what announces the address locally. A warning rather than a failure: the address still moves, but nothing tells the network it moved. Install iputils to clear it.
Certificate - whether the standby has a certificate covering the service name. If it does not, the promotion works and every service starts, but phones and browsers refuse to connect because the certificate does not match the name they requested. See TLS certificates.
Inbound URLs - any address an outside party has been given, such as a carrier callback, a messaging webhook or an OAuth redirect, needs to use the service name; if it names one of the two servers, that party keeps calling the server that failed. Check Inbound URLs lists each stored value and what happens to it during a failover. Read the Also held in column first: rows that say only this server are the provisioning addresses phones fetch their configuration from, and Repoint Provisioning Addresses sets those to the service name for you. Every other row names an outside system holding the other copy, registered at both ends, so both copies have to change together - work that belongs in adding an integration rather than in a failover.
Device provisioning - phones should be configured with both servers, so a phone that cannot reach one tries the other. The second server is written into each phone’s configuration file at the moment that file is generated, so setting it does not rewrite the files that already exist. This check warns when no second server is set at all, and otherwise counts how many configuration files carry it and how many are still on the old version - regenerating the device configurations clears that. Each phone then picks the change up when it next restarts or checks in, and until it does, that phone has one server and will not survive a failover. The count is of configuration files, not of phones that have fetched them: nothing on the server can tell a phone that has the new configuration from one that is simply idle.
Voicemail copied to standby - how much voicemail has been copied. Always advisory. It warns when the volume grows past a level worth reviewing, when copying has been turned off, and - on the standby - when that server holds voicemail that did not come from the active server.
Replication - both the database and MongoDB copies must be healthy. If either has stalled, the standby is behind and promoting it loses whatever did not arrive.

On a server that is not part of a pair the screen says so instead of drawing a diagram, and Promote to Active is switched off. If a server has been recorded but not yet paired, the screen says which role it was recorded as and that nothing has been applied - worth checking, for the reason given in Step 1.

Promoting the standby

Promotion makes the standby the active server. Browse to Configuration Manager on the standby using its own server name, and click Promote to Active.

Not every failing check stops a promotion

A promotion is usually run because the other server has already failed, so refusing one extends the outage. Failing checks are treated in two groups.

These stop and ask, because each one names a reason this server could not carry calls once it is active: the service name is missing or is one of the two server names; the method for moving the name is not working; the service name is not a name the call proxy answers for; this server does not know its role, or the recorded roles say the other server is still active; the block on serving is in a state this server cannot be released from.

These are reported and let through, because they describe something lost or degraded rather than a server that cannot carry calls: chat history that has stopped being copied, chat credentials that are not on this server, a certificate that does not cover the service name, a build one release behind, hold music that has not been pulled across. You are shown the list before the promotion runs, so read it - it is what to fix next - but the switch proceeds.

One more condition stops and asks, and it has nothing to do with readiness: the other server is still answering. Promoting then means both servers briefly handle calls, which is correct for a deliberate switchover and a reason to stop if you are still working out what is wrong.

Where a promotion does stop, you get a second confirmation naming exactly what is being overridden, and it continues only if you accept it.

Expect the replication check to be failing during a genuine outage. A standby copies from the active server, so when that server is gone the check reports a broken replica. That is a description of the outage, not a reason not to promote.

What a promotion does, in order

Saves a divergence report - how far each server’s data had progressed, written before anything changes. This is the only point at which the two can be compared, because the old server is eventually rebuilt.
Stops replication, allows writes, and takes the active role. Until now this server has been a read-only copy.
Restores file-based configuration - chat virtual hosts, chat sign-in credentials and contact lists, and the certificate if one was captured - then tenant audio and voicemail again, so that recordings made shortly before the failure are not missing.
Regenerates the telephony configuration from the database it now owns.
Removes the block on serving, so telephony and chat start here.
Claims the service name - adds the floating IP and announces it, or changes the DNS record and confirms the name answers with the new address. With external, nothing happens here.
Records the promotion, including where the divergence report was saved.

Every action offers a preview that prints these steps and changes nothing. Use the preview first.

After a promotion

The promoted server is now the active server. The old one is rebuilt as the new standby rather than switched back to.

Until then it is parked: it stays reachable so you can look at it, but it is blocked from serving. How long it stays that way is its retention window, seven days by default. When that window expires the old server is not rebuilt automatically - it confirms it is still blocked from serving and records that the window has closed, and the rebuild waits for you to ask for it. You can also rebuild sooner, as soon as you no longer need the parked server.

What a switchover does not preserve

Calls in progress end. The audio for a call is held on the server carrying it. Phones re-register and callers dial again, typically within a minute.
The last moments before the failure may be missing. Copying happens continuously but not instantaneously, and voicemail is copied on a five-minute cycle, so anything from that window stays on the failed server.
Chat clients resync in full when they reconnect rather than fetching only what they missed, so expect a delay on first connection proportional to the history in the conversation.
Connect users are re-authenticated, which happens in the background and does not require them to log in again.

Testing

Test a switchover before you have to rely on one. Most first attempts uncover something - a certificate that does not cover the service name, a TTL that is too long, a DNS credential that no longer works, phones that only know about one server. A deliberate test is also how you learn what the override confirmation looks like when the checks are otherwise healthy, so that during a real outage you can tell an expected failure apart from a genuine one.

Updating the software on a pair

Update the active server first, then the standby.

A platform update replaces the software, applies any changes the new version needs to the structure of the databases, and rewrites configuration derived from your settings. Only the first is local to one server: the database changes travel to the standby on their own, so applying them there as well would mean making the same change twice. The standby therefore does not make them - it recognises that it is following the other server and leaves both databases alone, which the installation log states in a line beginning “This server follows the other server of a redundant pair”. Its client-facing services also stay stopped, reported as held down (standby) rather than restarted. This applies to any package, not only the platform.

The same division governs scheduled maintenance: work that belongs to the pair, such as trimming call records to your retention setting or sending scheduled reports, is done by the active server only, while work that belongs to the machine continues on both.

To update a pair:

Update the active server, from Tools > System Update or by installing the package there. This applies the database changes and restarts services, so treat it as a maintenance window.
Update the standby. Nothing is interrupted, because it is not carrying calls. Its Manager accepts this even though it refuses configuration changes, because installing software is local to that machine.
Open Redundancy on both servers and confirm the check named Both servers run the same release passes on each.

Between the two steps the pair is briefly mismatched: the standby is running the previous release against the newer database structure. It will still promote if the active server fails in that window, which is deliberate, but a promotion in that state gives you the older software’s behaviour. If you update in the wrong order nothing is damaged - the standby applies no database changes whichever order you use.

Operating system updates go the other way round. Update and reboot the standby first: it is not carrying calls and its telephony services are held down, so a reboot brings nothing up that should not be running. Confirm the pair is healthy afterwards, then either take a maintenance window for the active server or promote the standby first.

Best practices

Use a service name that belongs to neither server. This is the most common setup mistake, and it fails only at the moment you need it to work.
Choose the move method that matches how your addresses are managed, and confirm it works before you rely on it. Where a provider assigns the addresses, that usually means DNS or the provider’s own facility rather than a floating IP. With external the platform does not check it, so confirm the name moved yourself.
If you choose DNS, lower the TTL well in advance, and press Test DNS Connection after entering the credentials and again whenever a token is rotated.
Pair the two servers while they are new. Copying a server that holds almost nothing takes seconds; the same copy on a system carrying a year of call records is a different job entirely.
Do not leave a pair half set up. A server recorded as the standby but never paired is still carrying calls and looks like a standalone system.
Bookmark the standby’s own server name. During an outage the shared name reaches the failed server.
Run Check Inbound URLs after adding any integration, and read the Also held in column: what says only this server can be corrected here, and the rest have to be changed at the provider as well.
Use the preview before every action, and test a switchover on purpose rather than discovering it during an outage.
Update the active server first, then the standby, and do not leave the pair on two different releases for longer than the update itself takes.
Put call recordings on object storage, and keep taking backups. Redundancy protects against losing a server, not against a change you did not mean to make.

HA Cluster - the other arrangement, two servers sharing a mirrored disk, built for a site by the Thirdlane services team, and how the two compare.
Server Health - each server’s report on its own condition, and how to point a monitoring system at both members of a pair.
Deployment Options
Domain and SSL Certificate
Network Topology
File Storage - where call recordings are kept, and the storage services supported.
System Update - applying platform updates, including the order to use on a pair.