search

Backup and restore (v8.5+)

hashtag
Introduction

Backup and restore functionality can help to safeguard against catastrophes, like unforeseen disk issues or power outages. To this end, Vectra Brain appliances provide the ability to back up data to an encrypted, compressed file. Data can be restored from this file at a later time. The CLI of the Brain is used to configure all backup and restore related settings.

Backups can be run manually or on a schedule. Any amount of external targets can be configure to upload backups to, e.g. SCP / SFTP servers, S3 buckets, or another brain via the Brain-to-Brain protocol. If external targets are enabled, any backup taken will be uploaded automatically to those targets after a backup run. Additionally, most targets can also be used as a source to retrieve backups from for restoration.

!! Please note that in deployments using the Respond UX where the UI is delivered from Vectra's cloud, when using network data sources (network Sensors), the Brain still must be backed up by the customer. Some parts of your deployment (metadata, detections, triage rules, etc) are backed up in Vectra’s cloud but the Brain appliance must still be backed up locally in your environment. If you are unsure of your deployment type, please see Vectra Analyst User Experiences (Respond vs Quadrant)

hashtag
What's New in Version 8.5+

In version 8.5 and higher of Vectra Brain software, backup and restore functionality has been updated to be more consistent in how the commands work for the various different options available in backup/restore. As a result, the majority of commands are different in some way. Please keep in mind the following:

  • Any existing backup targets will be retained.

  • Any existing schedule will be retained.

  • If you are set to backup to an external target, the setting will be retained.

  • Any allow list (white list) configured for Brain to Brain backup will be retained.

  • Any new configuration of backup/restore will need to use the new syntax as described in this KB article (the one you are reading).

hashtag
Vectra Brain Appliance Disaster Recovery (DR) / Migration Recommendations

Please see Vectra Brain Appliance Disaster Recovery (DR) / Migration Recommendations (v8.5+) for a detailed guidance to use in conjunction with the information here in DR and migration scenarios.

hashtag
Backup/Restore Frequently Asked Questions (FAQ)

chevron-rightExpand for detailshashtag

When migrating to a new Brain appliance, what is critical to configure during the restore process?

As per the Restoring Backups section of this article, there are some common options for running the restore command that are listed here as well. Its critical that the --replace option be used when migrating to a new Brain if the new Brain will fully replace the old Brain.

Common Options for the Restore Run Command

The restore run command (from-local, from-external-target, and from-url) also accept the following options:

  • --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.

    • 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.

How long do backups take to run?

  • Backup time will vary depending on the size of your deployment (how busy the network is, how many entities are being analyzed, what other data sources are configured, etc.

  • Backup downtime will vary depending on the size of the deployment.

    • The vast majority of backups will have no more than 10 minutes of downtime..

    • In a small number of heavily loaded deployments, Vectra support has seen up to 45 minutes of backup downtime. This is an outlier circumstance and not normal for the vast majority of customers.

    • The compression algorithm was changed for version 8.10 which has allowed for significant reductions in backup downtime.

What is unavailable during a backup?

Expand for more details - Brain functionality is limited during a backup.

  • Quadrant UX Deployments

    • The main UI will be unavailable during the backup.

  • Respond UX Deployments

    • The main UI will still be available during the backup.

  • All Deployments

    • HostID will not run during a backup, so new evidence for hosts and artifacts will not be observed during backup.

      • Existing hosts and artifacts will be unaffected.

    • Paired Sensors will buffer metadata generated from observed traffic until the Brain is available again to send to (after the backup completes).

      • Sensors can generally buffer 30-45 minutes of traffic before running out of buffer space.

      • This varies by Sensor and how busy the network is.

      • Busier networks will be able to buffer less.

      • Mixed mode Brains will not be able to buffer metadata as the Sensor functions are impacted during backup runs. It is recommended to run a dedicated Brain appliance to minimize data loss during backups.

    • Upgrading of the Brain or any paired Sensor will not be possible during backup/restore operations.

What is backup up / not backed up?

Expand for more details - Most configuration and detection data is backed up.

Included in backups:

  • Most Configuration data

    • See below for what is not included.

  • Detection data

    • Including the last 10GB of any Detection PCAPs

  • Algorithm learnings

  • Created Packet Captures (Selective PCAP)

    • Vectra Packet Capture stores up to 5GB of PCAPs (500 MB maximum for each PCAP).

      • Backup/Restore will back up and restore all PCAPs stored on the Brain.

    • For more details see: Using Vectra Packet Capture

Not included in backups?

  • DNS server configuration

  • NTP configuration

  • Timezone configuration

  • Sensor / Stream images

  • OS / IPMI passwords

  • IP configuration

  • Recall Custom Models (however, these are pulled down from the cloud hourly, so they will be preserved).

Sensors are not backed up. Only Brains are part of backup/restore.

What versions can I backup and restore to?

  • Backups can be taken on any supported version.

  • Restores can only be done to the same version they were taken on.

    • i.e. A backup taken on version 8.5 cannot be restored to a Brain running version 8.6.

Can I restore to a different type or model of Brain?

  • Backups can be made from physical, virtual, or cloud Brains.

  • Backups can be restored to any type of Brain, it does not matter what type of Brain the source Brain was.

Are backups encrypted?

  • All backups are encrypted using GPG with a Vectra-proprietary key. Backups can only be decrypted by Vectra support at this time.

What is the retention policy for backups?

Expand for more details - Local storage is limited to one backup. Brain to Brain backups are limited based on Brain type in the target folder. External targets can be limited with a "--max-backups" option.

  • When backing up locally to the Brain itself, one backup file can be stored locally.

    • When a new backup is taken, the older backup is deleted.

  • For Brain to Brain backups

    • Backup retention is managed automatically based on available disk space on the target Brain. Overall retention can therefore vary depending on individual backup sizes. Each time a backup is copied, previous backup files exceeding the maximum directory size (100GB on physical Brains, 20GB on virtual or cloud Brains) are deleted oldest-first until enough space is available for the new backup. For newly deployed brains you may see a larger amount of backups than a Brain which has been in production for a while. As Brains age, the backup file typically gets bigger and consequently the amount of backups will be reduce to avoid problems with disk space usage in the target Brain.

  • When using an external target (S3, SFTP, SCP), there is no size limitation enforced by the Brain.

    • You can limit the maximum number of backups that are stored in the target by using the --max-backups option when configuring the target.

    • For more details, please see the Configuring External Targets section.

What is the size of a backup file? Are incremental backups taken?

  • All backups are "full backups", as opposed to incremental or other strategies.

  • The backup size will vary with the number of entities, detections, and associated data on the system. It is typically expected that backups will reach a size of 5-50 GB, depending on the size of the deployment.

How often are backups performed?

  • An automated schedule can be set to backup once a week on the day/hour of your choice.

    • For more details, please see the Scheduling Backups section.

  • Manual backups can be run at any time.

    • Please keep in mind that functionality will be limited during a backup. Please see "What is unavailable during a backup" above for more details

hashtag
Migration Guide (for users of earlier versions)

chevron-rightPlease expand this section if you are an existing customer who is already familiar with configuring and running backups at the CLI of your Brain using versions prior to 8.5.hashtag

!! Customers who are new to backup and restore as of version 8.5 or later should ignore this section because it is only relevant for those who used the prior command structure/syntax to utilize backup and restore.

Unchanged commands:

These commands remain the same in the new system:

  • Clear Configuration

    • Command: backup clear

    • Description: Reset backup/restore configuration.

  • Run Backup

    • Command: backup run

    • Description: Make a backup of the current machine state. Sync to all external targets sequentially.

      • In the new version, this will not sync to other targets if "--local-only" is provided.

  • List Available Backups

    • Command: restore list

    • Description: List backups available on the local machine, as well as on any configured external targets.

Changed configuration and execution commands:

  • Configure External Targets

    • Old Command: backup configure-target

    • New Command: backup external-targets configure

  • Clear Local Backups

    • Old Command: restore clear

    • New Command: restore delete-version all --local-only

  • Configure S3 External Target

    • Old Command: backup configure-target --s3-bucket-name s3_bucket_name --aws-access-key-id aws_access_key_id --aws-secret-access-key aws_secret_access_key --aws-region-name aws_region_name

    • New Command: backup external-targets configure s3 --bucket-name bucket_name --access-key-id access_key_id --secret-access-key secret_access_key --region region

  • Configure SCP External Target

    • Old Command: backup configure-target --target-user target_user --target-server target_server --target-path target_path

    • New Command: backup external-targets configure scp --user user --server server --path path

  • Configure SFTP External Target

    • Old Command: backup configure-target --target-user target_user --target-server target_server --target-path target_path

    • New Command: backup external-targets configure sftp --user user --server server --path path

  • Configure Password-Auth SFTP External Target

    • Old Command: backup configure-target --target-user target_user --target-server target_server --target-path target_path --target-sftp-password

    • New Command: backup external-targets configure sftp --user user --server server --path path --use-password

  • Configure Brain-to-Brain External Target

    • Old Command: backup configure-target --target-brain target_brain --brain-key brain_key

    • New Command: backup external-targets configure to-brain --target-brain target_brain --token token

  • Test External Target

    • Old Command: backup test

    • New Command: backup external-targets test

  • Update Allow-list for Brain-to-Brain Backups

    • Old Command: backup accept-from-brains

    • New Command: backup from-brain allow-list

  • Refresh Brain-to-Brain Token

    • Old Command: token refresh

    • New Command: backup from-brain refresh-token

  • Run Local Backup

    • Old Command: backup run-local

    • New Command: backup run --local-only

  • Enable Scheduled Backups

    • Old Command: backup enable

    • New Command: backup schedule enable

  • Disable Scheduled Backups

    • Old Command: backup disable

    • New Command: backup schedule disable

  • Delete Backup Version

    • Old Command: backup delete-target-version

    • New Command: restore delete-version

  • Restore from External Target

    • Old Command: restore run --configured

    • New Command: restore run from-external-target <name>

  • Restore from Local Backup

    • Old Command: restore run --local

    • New Command: restore run from-local

  • Restore from URL

    • Old Command: restore run --http <url>, restore run --sftp <url>, restore run --scp <url>

    • New Command: restore run from-url <url> (accepts http://,https://,scp://, and sftp:// urls)

Changed commands related to showing backup information

  • Show Backup Download Link

    • Old Command: backup show-download-link

    • New Command: show backup download-link

  • Show Backup Events

    • Old Command: backup show (events included in summary)

    • New Command: show backup events

  • Show External Targets

    • Old Command: backup show (only 1 external target allowed. Included in summary)

    • New Command: show backup external-targets

  • Show Allow-List for Brain-to-Brain Backups

    • Old Command: backup show (allow-list included in summary)

    • New Command: show backup from-brain allow-list

  • Show Brain-to-Brain Token

    • Old Command: token show

    • New Command: show backup from-brain token

  • Show Public Key for SCP/SFTP Authentication

    • Old Command: backup show (key included in summary)

    • New Command: show backup public-key

  • Show Backup Schedule

    • Old Command: backup show (schedule included in summary)

    • New Command: show backup schedule

hashtag
Running Backups Manually

chevron-rightExpand for detailshashtag

To backup locally (even if you have external targets configured):

The output would look similar to this (the version and date is embedded in the file name):

"migration" just means the same thing as "backup" and is inconsequential.

To run a backup that includes external targets,remove the "--local-only" option as seen in the below example:

In this case a local backup was run and then a copy was uploaded to all configured external targets. If there were any failures, the output would show this.

hashtag
Scheduling Backups

chevron-rightExpand for detailshashtag

!! Please note - Since Brain functionality will limited during a backup run (see "What is unavailable during a a backup" in the FAQ section above), it is recommended to schedule backups for the time when your environment is least busy.

To set a backup schedule for Sundays at 11:00PM:

Example output:

!! Please note - The scheduled time is shown in the Brain's local time, but is stored in UTC time in the system. UTC time does not change with daylight savings time, so for the above example (CDT = UTC - 5), backups would happen at an hour earlier, at 22:00 CST during standard time (CST = UTC - 6).

To see the currently configured schedule:

Example output:

With the above schedule configuration, the backup will be local only. To enable upload to an external target (which must also be configured as shown in the Configuring External Targets section below), use the "--enable-external-upload" option as shown in the below example:

Disable it with "--disable-external-upload":

Scheduled backups are disabled by default. If you enable them but later decide to disable them, scheduled backups may be disabled with the following command:

hashtag
Configuring External Targets

It is a best practice to configure at least one external target and perform backups regularly to minimize any downtime or data loss in failure scenarios.

Note: The external connections bypass proxy settings, even if a proxy is configured.

hashtag
SCP and SFTP External Targets

chevron-rightExpand for detailshashtag

For either SCP or SFTP external targets, SSH authentication must be configured.

At the Brain's CLI as the "vectra" user run the following:

Example output:

!! Please note: This is an RSA key generated on-box for this use and is NOT the same as the SSL keys that can be provided by customers. This key cannot be changed by the customer.

On the receiving SCP or SFTP server:

  • Paste that key in the ~/.ssh/authorized_keys file.

  • Ensure the permissions of the ~/.ssh directory are not too open (e.g. sudo chmod 700 ~/.ssh).

  • Ensure the permissions of the ~/.ssh/authorized_keys file are not too open (e.g. sudo chmod 600 ~/.ssh/authorized_keys)

Then, follow the below instructions to set up the respective type of external target.

SCP External Targets

Expand for details

Back on the brain, use the backup external-targets configure scp command to create a new external target for your SCP server. For example, for [email protected]:/home/backups/, the command would be:

After setting the SCP target, the connection can be tested by:

Example output:

!! Please note that all configured external targets will be tested when using the above command.

By default, no limit will be set to the backups pushed to this target. To enable rotation after a certain number of backups, see the section on the --max-backups option below.

To enable weekly scheduled backs with external upload:

SFTP External Targets

Expand for details

Back on the brain, use the backup external-targets configure sftp command to create a new external target for your SCP server. For example, for [email protected]:/home/backups/, the command would be:

After setting the SFTP target, the connection can be tested by:

Example output:

!! Please note that all configured external targets will be tested when using the above command.

By default, no limit will be set to the backups pushed to this target. To enable rotation after a certain number of backups, see the section on the --max-backups option below.

To enable weekly scheduled backs with external upload:

Password-based SFTP Authentication

Alternatively, SFTP servers may use password-based SFTP authentication, instead of public-key.

In that case, pass the --use-password flag while configuring your SFTP target:

You will be prompted to input the SFTP password. Note: this password will be encrypted via AES, then stored in the appliance database. The key used to encrypt is stored locally on-box with minimal access permissions.

hashtag
AWS S3 External Targets

chevron-rightExpand for detailshashtag

Customers can configure an AWS S3 bucket to upload backups to.

Requirements:

  • AWS IAM account with the following permissions:

    • s3:PutObject, s3:DeleteObject, s3:GetObject, s3:ListBucket, s3:GetBucketPolicy, iam:SimulatePrincipalPolicy

  • Programmatic access to AWS S3 for this IAM user with:

  • AWS S3 bucket with policy permissions that allows the same S3 actions as described above for the AWS IAM account.

Configuring the S3 bucket policy permissions

Expand for details

  • Navigate in you AWS account to S3.

  • Choose the relevant bucket on which you want to apply the required permissions. Once inside, click on "Permissions", scroll down to "Bucket policy" and click on "Edit".

  • Paste the following code inside the policy. Replace the XXX with your bucket's name.

    • If you don't have an existing policy, paste this code inside the editor. Otherwise, add this code to the bottom of the page. This is only an example, the required permissions are: s3:PutObject, s3:DeleteObject, s3:GetObject, s3:ListBucket, s3:GetBucketPolicy.

Note - Please remove all comments (#...) from the lines in JSON above or it will fail to save it.

  • Click on "Save changes" in the bottom right to apply the new policy. It might take a few minutes for the new policy/updates to take effect.

Configuring the S3 target at the Brain CLI:

  • You will be prompted to enter the AWS IAM account's secret access key.

    • Alternatively, provide it with the --secret-access-key <ACCESS_KEY> parameter.

    • !! Please note: The secret access key will be encrypted via AES and then stored locally in the Brain's database. The key use to encrypt is stored locally with minimal access permissions.

  • For a bucket that has a nested directory structure, pass a path to the backups folder with the --path path/to/backups parameter. See the "Backup Location on Bucket" section below for examples.

To configure an alternate authentication region for retrieving the STS token required to access the bucket:

  • --auth-region is optional in v9.6 and higher of Vectra Brain software.

  • Without it being specified, the specified --region for the bucket is still properly used to backup to S3, but the auth token is retrieved from us-east-1 because S3 handles global authentication through STS by default there.

  • If you specify --auth-region, then STS token request goes to specified region.

  • In the example below, the auth region is set to eu-central-2:

After setting the S3 target, the connection can be tested by:

Example Output:

!! Please note that all configured external targets will be tested when using the above command.

To enable weekly scheduled backs with external upload:

Backup Location on Bucket

By default, backups will be placed in the root directory of the bucket. For example:

For a nested bucket structure, use the --path parameter to specify a subdirectory. For this example structure:

The --paths backups/brain-1 parameter should be used.

hashtag
Rotating Old Backups (--max-backups parameter)

This section applies only to SCP, SFTP, and S3 targets.

chevron-rightExpand for detailshashtag

For SCP, SFTP, and S3 targets, a --max-backups parameter may be passed during configuration. This will tell the brain to delete old backups on this target if the number of backups exceeds a certain count.

Example with an SCP target:

Now, if the user runs a backup, the Brain will:

  • Run the backup (locally).

  • Check how many backup files are on this external target.

    • If more than 4 it will delete the oldest backup.

  • Upload the backup.

When the backup complete there will be at most 5 backup files on this external target.

hashtag
Brain-to-Brain Backups

chevron-rightExpand for detailshashtag

Definitions, Facts, and Requirements

Setting another Brain as an external target can help you recover more quickly in the event that a failure is serious enough to cause the primary Brain to no longer function. Please keep in mind the following when using another Brain as an external target:

  • The "source" Brain is the Brain where the backup is performed.

  • The "target" Brain is the Brain the backup is copied to after it is completed on the source Brain.

  • The target Brain stores the backup, but does not automatically restore the saved backup into its configuration.

    • In this manner the target brain can be considered as a cold spare rather than a hot spare and the target Brain could be used in its own right as a Brain if necessary.

    • If you plan to be able to restore the source backup to the target Brain, then the target Brain should only be used for backup storage because you would over write its configuration when restoring the backup to it.

  • Source and target Brains can be of any type (physical, virtual, cloud).

  • Source and target Brains can be in any mode that includes Brain functionality (Brain or Mixed, but not Sensor mode).

  • Backup retention is managed automatically based on available disk space on the target Brain. Overall retention can therefore vary depending on individual backup sizes. Each time a backup is copied, previous backup files exceeding the maximum directory size (100GB on physical Brains, 20GB on virtual or cloud Brains) are deleted oldest-first until enough space is available for the new backup. For newly deployed brains you may see a larger amount of backups than a Brain which has been in production for a while. As Brains age, the backup file typically gets bigger and consequently the amount of backups will be reduce to avoid problems with disk space usage in the target Brain.

  • Source and target Brains must be able to communicate to each other HTTPS and SFTP is used for the backup transfer. Please make sure firewall rules allow bidirectional communication over:

    • TCP/443

    • TCP/22

  • The source Brain requires a token from the target Brain to be allowed to communicate with it for transfer of backups.

  • The target Brain can further be protected by configuring an allow list that only allows communication from specific other hosts (Brains) in your environment.

Configuring Brain-to-Brain Backup

Expand for details

A unique token is used to allow the source Brain to communicate with the target Brain. This token must be retrieved from the target Brain to complete the configuration on the source Brain.

On the target Brain:

Example output:

On the source Brain, use the obtained token and IP address to configure the backup target:

Example output:

!! Please note: The token will be encrypted via AES and then stored locally in the Brain's database. The key use to encrypt is stored locally with minimal access permissions.

To test your connection to the target Brain, from the source Brain execute the following:

!! Please note that all configured external targets will be tested when using the above command.

Example output:

To enable weekly scheduled backs with external upload:

Refreshing the Token

Expand for details

It is a good security practice to periodically refresh the token used for Brain-to-Brain backup. On the target Brain:

This will invalidate the old token and issue a new one. You will need to update the configuration on the source Brain with the new token. For example, if the target was named to-brain-1, run the following on the source Brain:

Specifying an Allow List on the Target Brain

Expand for details

By default, any host on your network that presents the token may use Brain-to-Brain backups. You can restrict this by using the following command to set an allow list on the target brain:

This will only allow 192.168.35.12, 192.168.35.34, and 192.168.35.56 to connect for Brain-to-Brain backups. To allow all hosts again, specify --all-hosts:

To see the currently configured allow list:

hashtag
Testing, Renaming, and Removing External Targets

chevron-rightExpand for detailshashtag

Listing Targets

Unlimited external targets may be configured. Each target is identified by a human-readable name.

To see the external targets currently configured via the show backup external-targets command:

Example output:

Custom Target Names

When configuring any external target, the --name parameter can be used to set a custom name for the target. This parameter is not required, and will be set to the following by default:

  • SCP targets: scp-n

  • SFTP targets: sftp-n

  • To-Brain targets: to-brain-n

  • S3 targets: s3-n

"n" is the number of total targets configured at the time the target was named.

Updating a Target

Use the name of the target to update its configuration. For example when using a custom name:

Example output:

Modifying to have new_user instead of ubuntu:

Example output:

Testing Connection to a Target

Test connection to external targets with the backup external-targets test command:

Example output:

Rename a target as follows:

Example output:

Removing a Target

To remove a target, use the following command (and use the name of the target you wish to remove, included below is a sample name):

Example output:

hashtag
Restoring Backups

chevron-rightExpand for detailshashtag

!! PLEASE NOTE: Prior to running any restore operation, please examine the "Common Options for the Restore Run Command" below to ensure that the proper options are selected if you are replacing a Brain. In particular, it is critical that you use the "--replace" option when migrating to a new Brain if the new Brain will fully replace the old Brain.

!! PLEASE NOTE:

  • You can not restore a RUX brain (also known as a cloud-bridge) onto another RUX brain (cloud-bridge).

  • You can restore a RUX brain backup onto the same RUX brain.

  • You can also restore a RUX brain (cloud-bridge) onto any non-RUX brain.

To run a restore, you will need to provide the filename of the backup that you are trying to restore along with the location of the file (local or external target).

Use the restore list command on the Brain that you will be restoring to in order to see a list of available backup files that can be restored.

Example output:

  • !! Please note that only the most recent backup file is kept on the local machine when backing up locally. In the above example, the backups for serial # VHE12100b75730baaaf48b91eeb04a4def0 are from Brain-to-Brain backups. The retention of Brain-to-Brain backup files is discussed in the Brain-to-Brain Backups section above (in the larger Configuring External Targets section).

  • "Location" in the above table shows "This machine" for a file that exists locally on the Brain that just ran the restore list command. The name of the external target is listed in "Location" for external targets.

To restore a backup file that resides on the local machine, execute the following:

  • --filename <FILE> may be omitted to use the local backup file taken for this machine. If there is none, the most recent backup file from Brain-to-Brain sync will be used.

For external targets you need to specify the external target and the filename. As an example using the sftp-2 target:

  • --filename <FILE> may be omitted to use the most recent backup file on the specified target.

If the file that you need to restore is not in the restore list output, but is otherwise accessible to the Brain, then a URL may be used. This is NOT common.

HTTP(S) URLs:

SFTP or SCP URLs:

Common Options for the Restore Run Command

The restore run command (from-local, from-external-target, and from-url) also accept the following options:

  • --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.

    • 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.

    • NTP settings do not restore upon execution of this command, ensure the NTP settings are updated appropriately after the restore has completed.

Deleting Versions

Users can only restore a machine from a backup with the same version as the current machine. To delete out-of-date backup versions, use the following commands.

To delete all backups on the current machine, and on any external targets, with version 8.3:

To delete all backups on the current machine, and on any external targets regardless of version:

For either command, add --local-only to only delete backups on the Brain you are logged into. This will not touch backups on any external targets.

hashtag
Additional Commands

chevron-rightExpand for detailshashtag

Example output (v8.5):

Clearing Backup Configuration

Executing the below command will reset the backup configuration to default values:

Showing Backup Events

Example output:

In version 8.6 and higher the "show backup summary" command will show the last backup duration. The duration shown will NOT include the time it took to copy the backup to any external targets.

Viewing Backup Configuration

To see the currently backup configuration:

Generating backup link for download

It will prompt a link which can for download the backup file.

This feature only works for Quadrant UX. Respond UX will prompt the link but the download page will not be available (it will be in the future).

hashtag
Troubleshooting Backup/Restore

chevron-rightExpand for detailshashtag

How to Receive Status Messages Related to Backup/Restore

Expand for details

You may receive status messages when running commands related to backup/restore. When running interactively, these can easily be viewed at the CLI. When you've setup a backup schedule it is necessary to monitor the audit log for messages related to backup/restore. Audit log messages can be sent as part of system logs which can be retrieved via API in Quadrant UX deployments, or sent via Syslog or Kafka for Quadrant UX deployments. If you are unsure of your deployment type.

For information related to using QUX APIs, please see:

Example Messages

Messages are sent for the following in the source Brain's audit log:

  • “Backup started”

  • “Error running backup: …” / “(Backup|Restore|Factory Restore) is already running. Try again later.”

  • “Backup complete”

  • “Restore started”

  • “Error running restore: …” / “(Backup|Restore|Factory Restore) is already running. Try again later.”

  • “Restore complete”

  • “Attempting backup copy to …”

  • “Attempting to rotate files on external target …”

  • “Backup copy to … completed. SHA-256 sum is …”

  • “Could not copy to …: …”

  • “Could not list backups on …”

  • “Failed to list directory on SFTP External target …”

  • “Could not delete existing backups on target system.”

  • “Attempting to stage backup to Brain-to-Brain Target …”

  • “Staging backup to Brain-to-Brain Target … failed. Error: …”

  • “Staging backup to Brain-to-Brain Target … succeeded”

  • “Failed to perform scheduled backup: …”

  • “Uncaught error running scheduled backup: …”

  • “Failed to upload migration-… to …”

Messages are sent for the following in the target Brain's audit log (when using Brain-to-Brain backups):

  • “Failure retrieving remote backup size from …”

  • “Successfully transferred remote backup from …”

  • “Failure transferring remote backup from …”

Local Backup Started/Completed :

External Target Copy Pending/Success:

Brain-to-Brain Common Issues

Expand for details

Incorrect or missing token

  • If the token is missing or incorrect, Brain-to-Brain backup test or execution will fail.

    • On the target Brain, execute the "show backup from-brain token" command to display the token and ensure this token is used to configure the external target on the source Brain.

Required firewall rules missing

  • The source and target Brains need to have TCP/22 and TCP/443 open between them. This should typically be configured bidirectionally so that either end can initiate a connection to allow the Brains to backup to each other.

SCP/SFTP Common Issues

Expand for details

Permission denied error

  • Ensure the user, server, and path are configured correctly for the target server.

  • Ensure the public key from the source Brain is copied to the ~/.ssh/authorized_keys file on the target server.

  • Check that the permissions are correct for both the .ssh directory and the authorized_keys file on the target server:

    • ~/.ssh must have 700 permissions, if not run the command (without the " marks at the start and end):

      • "chmod 700 ~/.ssh"

    • ~/.ssh/authorized_keys must have 600 permissions, if not run the command (without the " marks at the start and end):

      • "chmod 600 ~/.ssh/authorized_keys"

  • Does the backup target path have read/write permissions for the configured user?

  • Is there sufficient space on the target path?

  • Is there SSH Inspection or firewall level block between the Brain and target server?

    • The source Brain must be able to reach the external target server over TCP/22.

Command "backup external-targets test" succeeds, but a full backup run fails

  • This scenario usually occurs when connection to remote server has been closed abruptly or the network between Brain and target server is unstable.

Collecting Information for Vectra Support

Expand for details

If you need to open a Vectra support case to get additional assistance it will be valuable to provide information from your system(s) to help with the troublshooting process. Please collect the following information and provide it to Vectra in your support ticket.

From Source Brain:

From Target Brain (when using Brain-to-Brain backup):

Generate system report on the source Brain with the below command. It should take few minuted to run all the checks and collect logs:

Use the following command to list all reports:

Copy the URL associated with latest report (i.e. highest ID number). Put the URL ion your favorite browser to download the report.

hashtag
All Backup/Restore Commands (Syntax Examples)

This section duplicates many commands seen in the above sections. Please see the other sections for general backup/restore guidance.

chevron-rightExpand for detailshashtag

backup

backup clear

backup external-targets

backup external-targets configure

backup external-targets configure s3

backup external-targets configure scp

backup external-targets configure sftp

backup external-targets configure to-brain

backup external-targets remove

backup external-targets rename

backup external-targets test

backup from-brain

backup from-brain allow-list

backup from-brain refresh-token

backup run

backup schedule

backup schedule disable

backup schedule enable

restore

restore delete-version

restore list

restore run

restore run from-external-target

restore run from-local

restore run from-url

show backup

show backup download-link

show backup events

show backup external-targets

show backup from-brain

show backup from-brain allow-list

show backup from-brain token

show backup public-key

show backup schedule

show backup summary

PreviousBackup / Restore / DRNextDisaster recovery and migration (v8.5+)

Last updated

Was this helpful?