Migration process

Migrating to a new Brain is generally done when upgrading to a newer or more capable Brain or in situations where a failure in the original Brain is significant enough that the Brain must be entirely replaced. The overall process is similar to the DR case above, but in a general migration only case, you will not be moving back to the original Brain.

Prerequisites

Brain Versions: The version of the backup that is being restored, must match the major version running on the target Brain. The version of the backup is shown in the filename of the backup.

  • To ensure the new Brain is updated before the migration maintenance window turn on the new Brain and configure the MGT1 port so it can automatically update.

Target Brain Capacity: Ensure target Brain is of equal or comparable capacity/performance to the source Brain.

DNS Configuration: DNS TTL for the domain used for the Brain hostname should be set to 120 seconds to facilitate quick DNS updates during failover scenarios when pairing by hostname is used.

Backup Configuration:

  • It is a best practice to ensure backups are configured on the source Brain for at least one external target in addition to backing up locally.

  • If you only backup locally, in a failure in the source Brain may make the backup file unavailable for restoration on a replacement Brain.

  • If you backup locally, then both the new and old Brain will need to be on and be able to communicate with each other before the migration maintenance.

Connectivity:

  • For Brain-to-Brain backup use - TCP/22 and TCP/443 are open b/w the Brains.

  • For S3 external targets - TCP/443 is open to AWS S3 from the Brain.

  • For SCP/SFTP - TCP/22 is open from the Brain to the external target.

Definitions

  • Brain1 - Primary Brain

    • This Brain is the normal Brain in use for day to day operations.

  • Brain2 - Spare or Replacement Brain

    • This Brain may be in another data center or other secure location but it is online and reachable from Brain1.

Assumptions

  • Brain1 is configured with a hostname in your DNS and pairing of network Sensors was done by hostname.

    • If you have only an IP address configured for your Brain and it is not in DNS or your network Sensors were paired by IP, then you will need to adjust the procedure to re-pair the network Sensors to the Brain2 IP after a backup is restored to Brain2.

Migration Process

  1. Log into Brain2 and restore the most recent backup file available that originated from Brain1's serial number.

    • Be careful that you restore the correct backup if the target Brain stores backups for itself and for another source Brain.

    • Ensure that the --replace option was used when restoring the backup file (Brain must be connected to the Vectra Cloud).

  2. Reconfigure DNS to to point the Brain1 hostname to Brain2's IP address.

  3. Log into Brain2 GUI or your Respond UX UI and confirm it's operational with successful connectivity to all configured network Sensors (~ 10-15 minutes).

  4. Check for additional actions that may be required in Post Migration below.

Post Migration

  • For Quadrant UX deployments only

    • If you are a recall customer, please work with Vectra support to ensure your Recall deployment is properly configured to work with the replacement Brain.

  • If remote support was enabled through a proxy by Vectra support in the past for your original Brain, please work with Vectra support again to re-enable remote support through a proxy to your replacement Brain.

  • In the event that you are returning this device to Vectra, such as for an RMA, Vectra generally packs a return label in the same box as the replacement. You can simply put the faulty appliance back into the box and attached the return label and ship it to the destination.

  • If this is an RMA, please perform a factory restore of the old Brain before returning it (given it is still functional enough to do this).

  • If you no longer have other spare Brains, consider working with your Vectra sales team to purchase a new appliance or consider deploying a virtual Brain to use as a spare or target in a Brain-to-Brain backup scenario.

Last updated

Was this helpful?