Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Configuring external targets

How to configure external targets including SCP, SFTP, and S3. Brain to Brain backups. Rotating old backups. Testing, renaming, and removing external backup 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.

Please Note:

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

SCP and SFTP External Targets

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

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

show backup public-key

Example output:

ssh-rsa AAAAB3NzaC1yc2EAAAADAobsfuscated8GPHFpZVYZTQYqcagJKJnnGDXAfbnXLTJ9ILM4JlR6ykAsRTZ8vobsfuscatedtA85I0kgyRtms4JhNVLyBS7cjeobsfuscated+hoIBBXNobsfuscatedUfbDjjlaSPEpzpustKjEIj3obsfuscatedxIEzKNbmrObpSt3gavFuSJslSbLM0+f9FZKobsfuscatedCkCa5OlDNe9GUmxe7JtzgnBAKrVmpt3uGrtsyxgr12eBYlthrpi4/bvlF9vs04KobsfuscatedN28WJyCaeygQleafvC/mobsfuscateda7ywZz

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 for use with the QUX UI served from the Brain appliance. 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

    • For example you could: sudo chmod 600 ~/.ssh/authorized_keys

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

SCP External Targets

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 ubuntu@192.168.12.34:/home/backups/, the command would be:

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

Example output:

Please Note:

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

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 ubuntu@192.168.12.34:/home/backups/, the command would be:

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

Example output:

Please Note:

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.

AWS S3 External Targets

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

Please 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 in Bucket section below for examples.

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

  • --auth-region is an optional parameter.

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

All configured external targets will be tested when using the above command.

To enable weekly scheduled backs with external upload:

Backup Location in 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.

Rotating Old Backups (--max-backups parameter)

Please Note:

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

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.

Brain-to-Brain Backups

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

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:

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

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

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:

Testing, Renaming, and Removing External Targets

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:

PreviousScheduling backups and running manual backupsNextRestoring backups

Last updated

Was this helpful?