Disaster recovery and migration (v8.5+)

Introduction / Applicability

In the case of Vectra appliance failure that cannot be rectified or simply a desire to migrate to a new Brain appliance, backup and restore functionality can be leveraged. This KB article provides guidance for DR and migration scenarios for customers using version 8.5 and higher of Vectra Brain software. Earlier versions had different syntax for backup/restore commands. Any other DR/Migration/Restore related KBs that you find on the Vectra Support site that don't specifically say they are for version 8.5 and higher will be deprecated in the future.

This article provides high level guidance for DR/Migration strategies. For detailed guidance on backup/restore general functionality, syntax, and usage please see the following KB article:

• Backup and Restore for Vectra Brain Appliances (v8.5+)

Important Guidance for any Backup Restoration Done as Part of DR/Migration

The below are common options for use during a restore operation, of particular note is that the "--replace" option needs to be used when the Brain being restored to will fully replace the Brain the backup came from.

• --preserve-saml

  • Keeps the SAML configuration that was present on the target Brain prior to the restore.

  • For example, this can be helpful when SAML configuration is tied to an IP address that will be different on the target Brain.

• --preserve-ui-certs

  • Keeps the UI certificates that were present on the target Brain prior to the restore.

  • This can be useful when the restore target will have a different IP/hostname that would invalidate the UI certificate configuration.

• --replace

  • This option is meant to be used when a Brain is being fully replaced by another Brain and ensures that internal processes at Vectra properly link this new Brain with our back end as a replacement.

  • For customers running the Respond UX with network data sources, this option will ensure your replacement Brain can automatically connect to your GUI that is being served from the Vectra AI platform.

    • Please ensure that both brains are licensed with the same company account, if you're in doubt reach our support team

  • For customers running the Quadrant UX with non-network data sources (AWS CloudTrail, Azure AD & M365, etc), this option will ensure that these data sources will now report detections to the new Brain instead of the old Brain.

Please note:

The Brain must be connected to the Vectra cloud (at a minimum: update2.vectranetworks.com) at the time the restore is run for the back end to be properly linked. This should already be the case for customers using the Respond UX or Quadrant UX customers with non-network data sources because Vectra Cloud connectivity is required for either.

General Considerations

Regular Testing

• It is a best practice to periodically test your backup and disaster recovery processes to ensure they function correctly during an actual failure.

Firewall Rules

• Before any kind of recovery using the --replace feature is used, ensure that the brain can reach out to update2.vectranetworks.com to ensure communication between the brain and Vectra systems. See Firewall requirements for details and ensure that the rules are in place before proceeding.

• This is most important with a Respond/RUX restoration as it must check in to migrate all of the RUX instance information to the new brain, if it cannot it will break the integration and you must contact support for assistance.

Documentation

• It is a best practice to keep detailed documentation of your Brain configuration, backup schedules, and recovery procedures. This can assist in swift recovery and troubleshooting.

SSL Certificates

• SSL certificates (used for the UI in Quadrant UX deployments only) from the source Brain will be restored to the target Brain. If the cert included an IP, these may need to be regenerated for use on the target Brain. Please see SSL Certificate Installation for details.

Time to Restore

• The restore process takes generally the same amount of time that the backup took to run. The show backup summary command will show the last backup duration for the local backup that was done on the Brain that the command was executed on. The duration shown does NOT include the time it took to copy the backup to any external targets.

Sensor Communication / Re-pairing

• After a backup is restored to a target Brain, Sensors that were paired to a source Brain will either need to be re-paired to a target Brain or have the target Brain assume the hostname of the source Brain (if the Sensors were paired by hostname to the Source Brain).

  • If you are simply restoring a backup to the same Brain it was taken on (and the IP/hostname is the same), then re-pairing or DNS changes are NOT required.

• Please see Vectra Network Sensor Pairing Considerations below for more details.

Backup Configuration

• The configuration of backups is restored when a restore is run. If the target Brain requires a different backup configuration (different directory for example) adjust the backup configuration on the target Brain after the restore is run.

  • For Brain-to-Brain backups

    • During a restore, if an external target Brain in the backup configuration matches the target Brain during the restore, that external target will be deleted during the restore on the target Brain.

    • Allow lists for Brain-to-Brain backups are part of the backup configuration and will overwrite the allow list on the target Brain during the restore.

  • For S3 external targets

    • After a backup is restored, the S3 external target will function normally because all its configuration is maintained in the backup.

    • To download a backup to a replacement Brain you can replicate the S3 external target setup manually to be able to use the restore list command or use the restore run from-url command and specify a backup file HTTP(S) URL that is available from the Brain. Please note (S3 URLs i.e. s3://bucket-name are not supported)

  • For SCP/SFTP external targets

    • The public key used for backup/restore operations is not part of the backup and must be copied from the target Brain to the external target to allow these external targets to function normally after a restore from a source Brain.

    • To download a backup to a replacement Brain you can replicate the SCP/SFTP external target setup manually to be able to use the restore list command or use the restore run from-url command to specify a backup file URL that is available from the Brain

    • If you are using Brain-to-Brain backups in addition to SCP/SFTP external targets, it is a best practice to put the backup public key on the backup target server for all Brains that might have a restore run on them. This would allow SCP/SFTP external targets to continue functioning as normal after a restore is run.

Choosing the "Right" Backup File for a Restore

• restore list can be run on a Brain to see a list of backups that can be restored.

• One local backup is kept on the Brain where the restore list command was run if any backup has ever been run.

• Other backup files shown with a location of This machine may be present if the command was run on a Brain that was being used as an external target for Brain-to-Brain backup.

  • Be careful and examine the Origin Serial Number column closely to see which Brain the backup file was taken from.

• Other backup files shown will be available in configured external targets.

• Please see Backup Configuration above for how to make external targets functional after a restore has been run.

Vectra Network Sensor Pairing Considerations

Backups only happen on Vectra Brain appliances when they are configured to perform them. Sensors are not backed up and do not store overall deployment configuration data. Please keep in mind the following for Vectra network Sensors:

When a source Brain backup is restored to a target Brain or a Brain IP or hostname is changed, Sensors will need to know how to communicate with the Brain.

• This can be accomplished by using the set brain command at the CLI of the Sensor to set a new hostname or IP of the Brain.

• If you paired by hostname, and the target Brain will assume the hostname of the source Brain after a restore, Sensor state (pairing information) is retained and the new Brain will automatically begin working with the existing Sensor(s) after the existing tunnel(s) are terminated.

• In all cases, existing tunnels have to terminate to re-establish connection to a new Brain. This can be accomplished a few different ways.

  • Naturally, because the original Brain is no longer reachable due to firewall change, hardware or software failure, etc.

  • Using the set brain command at the CLI will terminate an existing tunnel and attempt to start pairing with a new Brain.

    • del brain can be used to break the tunnel but not set a new Brain location.

  • In normal operation, the Sensor can simply be unpaired from its existing Brain. To use the Unpair option, the Brain must be connected to the Vectra Cloud and the Sensor must be powered on with an active tunnel to the original Brain.

    • Navigate to Configuration → COVERAGE → Data Sources → Network → Sensors, click on the Sensor you wish to unpair and click on the Unpair button.

    • After unpairing which could take a few minutes, the status of the Sensor should change to Available.

  

  • Using the Force Unpair option in your Vectra UI for the target Sensor.

    • This will unpair the Sensor from the original Brain and when the Sensor attempts communication to the original Brain the tunnel will not function.

    • Force Unpair is the same as deleting for a vSensor. You cannot delete a physical Sensor (talk to Vectra Support if this is required).

Sensors can be paired to a Brain using an IP address or a hostname.

• Pairing by hostname:

  • When Sensors are configured to pair by hostname, it makes restore scenarios easier to manage when the target Brain's IP address cannot be the same as the source Brain's IP was.

  • After a restore completes, your internal DNS records will need to be updated to point the Brain hostname to the new IP that will be used for the target Brain's management IP address.

  • Paired Sensors will be able to automatically re-pair with the new Brain once the DNS is changed. This is because the backup contains Sensor state information.

• Pairing by IP address:

  • When pairing by IP, if the IP of the Brain changes or you want to pair to a new Brain, you must use the set brain command to point to the new IP for the Brain.

• Sensor Registration Token usage:

  • If you have a Brain that will not be restored from backup that you wish to pair an existing Sensor to, this is possible via the use of a Sensor Registration Token.

  • Retrieve or generate a current Sensor Registration Token from Configuration → COVERAGE → Data Sources > Network > Sensors > Sensor Configuration in the Vectra GUI.

  • Perform the del brain command at the Sensor CLI.

  • Perform the set registration-token <token> command at the Sensor CLI.

  • Perform the set brain <IP or Hostname> command at the Sensor CLI.

  • The Sensor should become Available for pairing in the new Brain.

• For full Sensor documentation including general pairing information, please see the deployment guide for your Sensor or pairing appliances.

Move on to DR or Migration

DR (Disaster Recover) processMigration process