High availability (hot standby)
A hot standby is a second BackupMunk server, ideally at another site, that continuously copies the primary server's data. If the primary's site is lost, an administrator promotes the standby and it carries on with the same clients, destinations, credentials, encryption keys and backup catalog. Agents switch to it on their own. Promotion is always manual. There is no automatic failover, so a network split can't create two primaries. What the standby copies Copied to the standby Not copied Server secrets: the agent-token signing key and the key that seals stored credentials and destination keys Sign-in sessions. Users sign in again after a failover. Users, single sign-on providers and role mappings Each server's own Public URL and high-availability settings Clients (including their agents' public keys) and registration keys The primary's list of standbys Destinations, with their sealed credentials, encryption keys and recovery passphrase blocks Backups, assignments, settings and the license Runs, the stored-backup catalog, retention history and the audit log Settings and other small tables are copied in full every 30 seconds. History (runs, catalog, retention and audit) is copied incrementally, with a full reconciliation about every 10 minutes. Replication is asynchronous, so the standby can be up to about 30 seconds behind. Requirements The same BMENT_ENC_KEY on both servers. The copied secrets are sealed under it. Pairing compares the two keys' fingerprints and refuses to pair if they differ. Each server shows its Key fingerprint under Settings → High availability. The standby must reach the primary over HTTPS. The standby pulls from the primary. The primary never connects to the standby. Agents must be able to reach the standby's public URL. Set it on the standby under Settings → General → Public URL before pairing, because a standby's console is read-only. One level only. A standby can't have standbys of its own. The standby carries the primary's license and counts as the same installation, not a second activation. Pair a standby Install a second server as described in Deploy the server, using the same BMENT_ENC_KEY as the primary. Set its Public URL. On the primary, open Settings → High availability. Under Standby servers, enter a name, for example dr-site-east, and choose Add standby. Copy the pairing token. It's shown only once. On the standby, open Settings → High availability → Make this server a standby. Enter the Primary URL and the Pairing token, tick Replace this server's data with the primary's, and choose Pair as standby. [!WARNING] Pairing replaces everything in the standby's database with the primary's data. The standby restarts as a read-only standby. Sign in with an account from the primary. The primary tells its connected agents about the new standby straight away, so they know where to go if the primary is lost. While a server is a standby The console is read-only. A banner on every page shows the primary it copies from and when it last synced. Settings → High availability shows the replication status, the last error if syncing is failing, and the number of records copied. It refuses agents, so the fleet stays on the primary. It runs no background work: no stalled-run checks, catalog scans, copy repair, license emails, audit clean-up or notification digests. On the primary, Standby servers lists each standby and when it last synced. Fail over to the standby Make sure the primary really is down, or is being retired. Promotion isn't reversed automatically. On the standby, open Settings → High availability. Under Promote to primary, type PROMOTE and choose Promote this standby. The server restarts as the primary, with a higher epoch (a counter that goes up with each promotion). Agents that can't reach the old primary try the other servers they know about, and attach to the first primary whose epoch is at least the highest they've seen. Their schedules keep running locally the whole time. Only reporting pauses…
BackupMunk Enterprise documentation