Part 2 · Appliance & Site Configuration
Backup and Failover
A single B Series Appliance is a single point of failure. This module covers the two distinct answers PRA gives to that problem — configuration backups you restore by hand, and a live primary/backup appliance pair that can take over automatically — and, critically, where the line between them sits.
Two different safety nets, not one
Admins new to PRA often use "backup" to mean one thing, but the product actually offers two mechanisms that solve different problems and are configured in different places. A configuration backup (Management > Software page) is a downloadable snapshot of your settings — a file you'd restore onto a freshly reimaged or replacement appliance after a total loss. Failover (Management > Failover page) is an ongoing, live relationship between two running appliances, where a secondary appliance continuously synchronizes from the primary and can take over serving traffic within minutes of the primary going dark. One is a point-in-time insurance policy you hope never to open; the other is standing infrastructure. Most production PRA deployments that care about uptime run both — failover for continuity, and periodic configuration backups as a belt-and-suspenders recovery path if something corrupts both appliances at once (or if you're migrating rather than recovering).
Configuration backups
From /login > Management, the Backup settings section lets you generate a password-protected backup file of your software configuration. BeyondTrust's stated best practice is to take a fresh backup every time you change appliance settings, since the backup is what speeds recovery time if hardware fails — and, in some cases, is what BeyondTrust support uses to stand up temporary hosted service while you sort out replacement hardware. Two independent choices shape what a given backup contains:
- Backup password. If you set one, you cannot restore from that backup file without supplying the same password again — treat it like any other credential that, if lost, makes the backup useless.
- Include logged history reporting data. Checked, the backup bundles session logs; unchecked, it's configuration only. A configuration-only backup is smaller and faster and is the right choice when you're backing up purely to protect settings, not session history.
Restoring is the mirror image: upload the backup file, supply its password if one was set, and the appliance overwrites its current site settings with whatever was captured in the file.
The Vault encryption key is a separate artifact
One detail trips up more admins than any other part of backup/restore: the Vault encryption key — the key used to encrypt and decrypt every credential stored in BeyondTrust Vault — is not automatically part of a configuration backup in the way you'd expect. It has its own dedicated Backup Vault Encryption Keys action. If you restore a configuration backup onto a new appliance without also restoring the matching Vault encryption key backup, the restored configuration will reference Vault credentials it cannot decrypt.
An admin dutifully downloads a configuration backup before decommissioning old hardware, restores it cleanly onto the replacement appliance — and then finds every Vault credential unusable, because the Vault encryption key backup was never taken (or was taken once, months earlier, and is now out of sync with credentials added since). Treat the Vault encryption key backup as a mandatory companion to every configuration backup, not an optional extra, especially right before any hardware swap or DR test.
Failover: the primary/backup relationship
Failover synchronizes data between two peer B Series Appliances running the same software package (matching Product Version and Product Build — visible on the Status page) for a single site. DNS directs normal traffic to the primary appliance, where every configuration change is actually made; the backup appliance continuously pulls a copy of that state so it's ready to take over if the primary goes down. The relationship is established from the intended-primary appliance's /login > Management > Failover page, by entering connection details for the backup (its hostname/IP and TLS port) and reverse connection details telling the backup how to reach back to the primary.
Establishing the relationship requires the two appliances to share an identical Inter-Appliance Communication Pre-shared Key, set on the Security page covered in Module 4 — mismatched keys are the most common reason a failover relationship simply refuses to establish. Once connected, an initial full data sync kicks off automatically (starting within about 60 seconds), and this sync brings over all user accounts, all /login configuration settings, files in the file store, logs, and recordings — everything on the backup is overwritten by what's on the primary. From then on, you set an automatic sync interval, or force one on demand with Sync Now.
Triggering a failover: manual vs. automatic
A role swap — the backup becoming primary and vice versa — can happen two ways. Manual: an admin clicks Become Backup on the primary or Become Primary on the backup, optionally checking a box to force a fresh data sync immediately before the swap (during which all users on the current primary are disconnected). Automatic: if Enable Automatic Failover is turned on in Backup Settings, the backup appliance itself monitors reachability of the primary, and if the primary stays unreachable longer than the configured Primary Site Instance Timeout, the backup promotes itself — but only if both appliances are on the same subnet, since built-in automatic failover depends on the Shared IP method described below. Cross-subnet automatic failover requires driving the swap yourself via the failover API instead.
Regardless of trigger, actually rerouting client traffic to the new primary depends on which of three network methods you've set up:
| Method | How it works | Trade-off |
|---|---|---|
| Shared IP | Both appliances can hold the same IP in /appliance, but only the active primary has it enabled | Fastest, no propagation delay; requires both appliances on the same subnet (not supported on AWS) |
| DNS Swing | Repoint the site's DNS record from the primary's IP to the backup's IP | Works across subnets; subject to DNS propagation / TTL delay |
| NAT Swing | Repoint the NAT device's routing from the primary's IP to the backup's IP | Works across subnets; no DNS propagation lag, but requires coordinated network-equipment changes |
Best-practice backup settings: normal vs. maintenance roles
The documentation is explicit that Backup Settings (Enable Backup Operations, Auto Data-Sync Interval, Enable Automatic Failover, Primary Site Instance Timeout) are per-appliance, not synchronized, and only take effect when that appliance is currently in the backup role. The recommended pattern is to designate one appliance as the "normal" primary and the other as the "normal" backup, and to leave Enable Backup Operations off on the normal primary — because if the normal primary ever temporarily becomes the backup (say, during planned maintenance on the other box), you don't want it firing off probing, data-syncs, and administrator alert emails while it's only wearing the backup hat for a few hours.
Failover data sync is one-directional and overwriting: whatever is on the primary replaces whatever is on the backup, every time. If you make configuration changes directly on what's currently the backup appliance — even temporarily, during a maintenance window where roles have swapped — those changes are lost the moment the roles swap back and a sync runs, unless you deliberately tracked and re-applied them. Planned-maintenance procedures explicitly call out logging every change made to the temporary primary so it can be manually reapplied afterward.
Certificates must match
The primary and backup appliances must present identical SSL certificates, otherwise BeyondTrust clients will refuse to trust the backup once it takes over. The documented workflow is to export the certificate (with private key and chain, optionally passphrase-protected) from the primary's /appliance > Security > Certificates page and import it into the same page on the backup. BeyondTrust specifically advises against using Let's Encrypt certificates for failover pairs, since Let's Encrypt issuance is tied to a single appliance's DNS hostname and doesn't transfer cleanly to a peer.
What gets restored — and what doesn't
It's worth being precise about what a failover sync actually preserves versus a configuration backup/restore, because they're not identical: failover sync carries user accounts, /login settings, file store contents, logs, and recordings continuously between two live appliances; a downloaded configuration backup is a point-in-time snapshot of settings (and optionally session history) meant for restoring onto a single appliance, with the Vault encryption key handled as a separate artifact in both cases. Neither mechanism is a substitute for the other — failover protects against an appliance going offline; backups protect against needing to rebuild from nothing.
Detecting and resolving conflicts
If both appliances end up believing they're primary (or both believe they're backup) — typically after a network partition or an automatic failover that wasn't cleanly resolved — the Failover Status page surfaces an explicit conflict warning. You can resolve it manually by logging into the appliance that should hold a given role and clicking Become Backup or Become Primary accordingly, or let PRA sort it out automatically via the Fix This Error button, which inspects signals like which appliance currently has the shared IP enabled or which one DNS currently resolves to. Whichever appliance ends up in the backup role afterward has its /login settings overwritten by the primary — with the one exception of failover settings themselves, which are not synchronized.