Data Recovery

Once an appliance or site has been repaired and/or replaced, it is usually necessary to restore its settings and data.This is always necessary in cases where BeyondTrust has shipped an entirely new appliance from the factory. The settings and data to restore includes /appliance settings and certificates as well as /login users and configuration. Before restoring any of this, first complete the appliance IP network configuration. Once that is done, remaining /appliance configuration, certificates, and /login settings can be restored remotely as described below.


When an appliance in a failover pair has failed and been replaced, the second appliance in the pair should be servicing clients while the failed appliance is restored. The restore process for the failed appliance varies depending on its type. Once the appliance has been restored, restore its certificates either from a backup or by exporting them from the primary appliance.

Once the failed appliance is online and has the primary appliance's certificates installed, restore its /login administrative interface. Since the primary appliance should already have all settings and data, it us generally not advisable to restore backup files to a backup appliance manually. However, installing a /login site package is needed. Once that is done, establish failover from the active appliance to the repaired one and sync them as described in Establish the Primary/Backup Failover Relationship Between Two Appliances .

It is still possible to download and restore backup files to failover appliances; however, it is not ideal unless the primary failover appliance is missing crucial data that exists only in a backup file. If a backup is restored, failover settings are overwritten with the values contained in the backup. This includes both /login > Management > Failover settings and the Inter-appliance Communication Pre-shared Key found in /login > Management > Security. This means that if a backup is restored to an appliance in active failover, the failover connection is likely to have issues. Because of this, the best practice is to break failover, restore the backup, reset the pre-shared key, and re-establish the failover relationship. For details, please see Failover Dynamics and Options .

If the restored appliance in a failover pair has formerly been the primary appliance in the failover relationship, it re-enters the failover relationship as the backup appliance. Sometimes, it can remain this way, but in other scenarios, it is desirable to make it primary once again. If this is the case, follow the instructions in Establish Failover for Planned Maintenance. The process varies slightly, depending on how the network is routing traffic to the primary appliance. The routing methods are IP failover, DNS swing, or NAT swing.


Like failover, Atlas clusters have special requirements. An Atlas cluster typically consists of a failover pair of master appliances that route traffic between a number of traffic node appliances. If one of the master appliances fail, refer to the failover recovery guidelines described immediately above. If one fails, follow these steps:

  1. Restore the appliance.
  2. Install a /login site package on the appliance.
  3. Add the recovered appliance back into the Atlas cluster. Please see Configure the Traffic Nodes in an Atlas Cluster for more information.
  4. Sync the recovered appliance in order to restore the /login settings.
    1. Log into the primary master appliance's /login administrative web interface.
    2. Browse to Management > Cluster.
    3. Click Sync Now.

Once completed, the traffic node is fully operational. To test, follow these steps:

  1. Log into the traffic node's /login web interface.
  2. While logged into a representative console from a geographic region that is expected to route through the restored traffic node, check Status > Connected Clients.
  3. If the value for connected representative consoles increases by one immediately after authenticating to the console, the traffic node is working.

If a backup is restored from an Atlas master node, it does not overwrite the existing Atlas configuration. As a result, copying the configuration of a master node to each of its traffic nodes is supported; however, manually performing this task is not standard practice. Synchronizing data from the primary master appliance is the standard method for restoring /login settings to a traffic node.

Recover Certificates

BeyondTrust requires SSL certificates. If any client software from a previous appliance is expected to reconnect with the replacement appliance, this appliance needs a copy of the original SSL certificate(s). Most Cloud Appliances share a standard certificate which validates the BeyondTrust Cloud domain. If the certificate and domain are changed, the non-standard certificate must be restored. Hardware and virtual appliances have no such standard configuration and therefore have unique certificates configured by the administrator that must be restored in a disaster recovery scenario. The steps to restore certificates are given below, and they assume that the necessary steps have been taken to bring the web interfaces online.

The steps to bring the web interfaces online vary based on the appliance type.

  1. Log into the /appliance web interface of the Secure Remote Access Appliance.
  2. Go to Security > Certificates.
  3. If a Secure Remote Access Appliance certificate is listed, ignore it. This is a standard certificate that ships with all Secure Remote Access Appliances.
  4. In Security :: Certificate Installation, click Import.
  5. Browse to the certificate file.
  6. Enter the password for the certificate file.
  7. Click Upload.

The Secure Remote Access Appliance certificate appears in the Security :: Certificates section.If the certificate was issued by a third-party Certificate Authority (CA), the intermediate certificate and root certificate are also listed here. If your appliance uses a CA certificate, all intermediate certificate and their root certificate must be present for the appliance to function properly. Here is a description of each type of certificate:

  • Self-Signed Certificate: This has identical values for Issued To and Issued By and have the appliance's fully qualified domain name (FQDN) in the Alternative Name(s) field.
  • CA-Signed Certificate: This has an Issued To field and/or an Alternative Name(s) field matching the Secure Remote Access Appliance's FQDN. If a CA-signed certificate exists, the appliance also has one or more intermediate and/or root certificate(s) listed on the Certificates page.
  • Intermediate certificates: These have different Issued To and Issued By fields, neither of which is an FQDN. Usually, there are only one or two intermediate certificates. Sometimes, there are none, depending on the CA.
  • Root certificate: This has identical values for the Issued To and Issued By fields, neither of which are an FQDN. Every CA-signed certificate must have exactly one root certificate.

If a self-signed certificate is being used, a warning is present beaneath it. The warning is expressing that this kind of certificate should normally be used only temporarily until a CA-signed certificate is obtained. If a CA-signed certificate has already been obtained and one or more of its intermediate and/or root certificate(s) are missing, a warning appears beneath the CA-signed certificate. To resolve this, contact the CA. For more information, please see FAQ 755 in the BeyondTrust Technical Support Self Service Center .

  1. Once there are not any certificate warnings, click the Assign IP link in the certificates entry for the appliance's CA-signed or self-signed certificate.
  2. At the bottom of the resulting page, check the IP address of the appliance.
  3. Click Save Configuration. This completes the restore process for the certificate(s). However, the appliance still needs /login restored before it is fully operational.

Recover /login

Unlike /appliance, the /login administrative web interface is not installed by default on new appliances. Therefore, in cases where a new virtual appliance has been installed or a new hardware appliance has been shipped, the new appliance does not usually have a /login administrative web interface. If the appliance was repaired or restored from a snapshot instead of replaced or re-installed, the repaired appliance still has a /login site package installed, but it may be necessary to upgrade the site to the same version as the failover appliance or to a version compatible with the backup file. In these cases, contact BeyondTrust Support for the necessary /login site updates. To get the updates, send BeyondTrust Support an email including these items:

  • Screenshot of the /appliance Status page
  • Appliance FQDN registered in DNS
  • Version of the most recent backup file

After receiving this information, Support registers the appliance on the BeyondTrust update servers, builds the necessary update package(s), and sends the installation instructions. There are one or more base software updates to install prior to the /login site package. Follow the instructions from BeyondTrust Support to update the appliance and log into the /login web interface, using the default admin and password credentials. The system forces the password to be changed at login.

In failover and Atlas scenarios, /login data is recovered using data synchronization rather than backup files. Outside of this, the .nsb backup files should be saved in order to restore /login settings, users, and data. However, before restoring a backup file, take into account the BeyondTrust product release version from which the backup was downloaded as well as the version of the site receiving the backup file. BeyondTrust does not test restoring backups from every version to every other version. Only backups from the supported upgrades of a particular version are tested. Supported upgrade versions are listed in the release notes for each version. Release notes are available at

The version of a particular backup can be found by checking the filename of the backup. By default, BeyondTrust backup file names begin with bomgar followed by the BeyondTrust product release version of the backup, the name of the site which generated the backup, the date on which the backup was downloaded, and the unique ID of the backup file. Check the version of the site to which the backup is being uploaded to by viewing the Product Version field on the /login > Status > Information page.

When attempting to restore backups from an old release version to a newer version of BeyondTrust not listed as the backup's supported upgrade version, unexpected issues and/or data loss can occur. When attempting to restore backups from newer versions of BeyondTrust to older, major issues occur. This is simply not supported. However, as long as the rules concerning release versions are followed, backups can be successfully restored between physical appliances (i.e., B200, B300, and B400) and virtual appliances and between physical appliances of different hardware revisions.

Once the restore method is validated, restore the /login site backup by following these steps:

  1. Browse to /login > Management > Software.
  2. Locate Software :: Restore Settings.
  3. Click Choose File.
  4. Select the backup file using the file browser.
  5. Enter the backup password, if one was assigned.
  6. Click Upload Backup.

The backup password is assigned by the administrator who downloads the backup originally. If it is lost, the backup cannot be restored. Once it is restored, all users (including the local administrator), settings, and most data are restored to the state at which the backup was originally downloaded.

After /login is online and the backup is restored, the appliance should be fully operational, assuming the network's traffic has been properly routed. To test the appliance:

  1. Open the representative console.
  2. Log in with the user credentials that worked prior to the failure event.
  3. Verify that all Jump Clients, Jumpoints, options, and settings function as expected.

There should be no need to deploy new client software. Instead, the original clients should reconnect with the new appliance automatically.

Return the Defective Appliance

In cases where you have replaced a failed hardware appliance, it will be necessary to dispose of the failed hardware. First, you may wish to wipe the appliance of all sensitive data. You can wipe the appliance by taking these steps:

  1. Log into the /appliance web interface of the defective appliance.
  2. Browse to the Status > Basics page.
  3. Click Reset Appliance to Factory Defaults.
  4. Wait for the reset to complete.
  5. Click Shut Down This Appliance.

Once done, ask BeyondTrust Support for a return shipping label, if you have not been sent one already. Once you have the return label, use it to ship the appliance back. Many administrators choose to use the packaging materials of the replacement appliance to return the defective one.