Perform Failover for Unplanned Maintenance

 

These flows depend on using the backup settings described in the topic Best Practices for Primary and Backup Environments. This method may result in situations where /login interface settings might be lost, but that can be mitigated if you are careful to track what changes were made in /login during the maintenance period.

This flow assumes the normal primary site is already down and unreachable from the backup. If it is reachable, use the Perform Failover for Planned Maintenance. This flow also assumes automatic failover is off. If automatic failover is on and has already occurred, you can skip down to step 3 for the appropriate flow.

If no changes have been made in the /login interface since the last data-sync, use the first flow. Otherwise, use the second flow.

Unplanned Maintenance with No Recent Change in /login

  1. Go to the backup failover page at /login > Management > Failover.
  2. Click Become Primary and wait.
    • This site will be missing any session data and recordings since the last data-sync.
    • Care should be taken to not make changes to settings in /login while the backup is acting as primary. Any changes that are made will be lost when the site is made the backup again. Any support session recordings and data will not be lost, however.
  3. If necessary, perform a DNS or NAT swing after you see that the roles swap.
  4. Perform maintenance on the primary.
  5. When the primary is ready to resume its normal duties, repeat steps 1-3 to reverse the roles, but check the Check this box to pull a data-sync from the site instance while becoming the backup BEFORE clicking Become Primary.

Unplanned Maintenance with Recent Changes in /login

  1. Go to the backup failover page at /login > Management > Failover.
  2. Click Become Primary and wait.
    • This site will be missing any session data, recordings, and /login setting changes since the last data-sync.
    • Care should be taken to not make changes to settings in /login while the backup is acting as primary. Any changes that are made will be lost when the site is made the backup again. Any support session recordings and data will not be lost, however.
  3. If necessary, perform a DNS or NAT swing after you see that the roles swap. If configured for Shared IP, skip this step.
  4. Perform maintenance on the primary.
    • During this time, track any changes made in /login of the new primary site with the exception of the failover page.
  5. When the primary is ready to resume its normal duties, repeat steps 1-3 to swap roles back.
  6. Re-apply any settings changes in /login from the changes list.
  7. Perform a data-sync.

Instead of going to the /login interface to change roles, you can use the BeyondTrust failover API. For details, see Best Practices for Primary and Backup Environments.