Follow

Brain to Brain Automated Backups

Backups can also to be performed from the primary brain to a secondary brain.

Brain to Brain backups can be setup concurrently and will run bidirectionally if configured this way.  If you wish to backup the data to a remote file server please view the article available here: SFTP/SCP backups.

The source will be the primary brain or where the actual backups is performed. The target will be where the backups is copied via SFTP.  The target brain stores the saved backup but does not automatically restore the saved backup into its configuration.  In this manner the target brain is a cold spare rather than a hot spare and may be used as a brain in its own right until restoration of the backup is required.

The backup configuration is completed on the source brain, resulting in the source brain backing up data locally and copying the resulting backup data to the target brain.

The source brain and target brain must be able to communicate bidirectionally via HTTPS (443) and SSH (22).

THe duration of the backup copy to the secondary can vary restore list on the secondary will only be populated once the transfer is completed.

Brain to Brain backup configuration

The following process may be used to configure a new brain to brain automated backup from the Vectra CLI using the vectra user.

  • On the target brain retrieve the authentication key and whitelist the source brain IP:
    token show
    backup accept-from-brains [ hosts ] [ --all-hosts ]
    backup enable
  • On the source brain configure the backup as follows, replacing the word KEY with the key retrieved in the previous step:
    backup configure-target --enable-brain --target-brain SERVER --brain-key KEY
    backup enable

* The backup once completed on the source brain will make the backup is available.  Once an hour (via a cron job) the destination brain will check for the backup and pull it from the source brain.  This can result in a slight delay between the backup completion on the source brain and the transfer to the destination brain.

 

Testing the backup configuration

To test if the configuration issue the following command on the primary brain:

backup test

Output would be similar to if both SFTP/SCP and Brain to Brain backups are configured

Testing backup copy to file server...
Test copy to file server successful.
Check for a file named "sched_backup_testiqDdW3" on the target. 

Testing backup copy to target brain...
Brain connection check successful.

Retention period

Backup retention is managed automatically based on available disk space. Overall retention can therefore vary depending on individual backup size.

Each time a backup is copied, previous backup files exceeding the maximum directory size (100GB) are deleted oldest-first until enough space is available for the new backup

 

Restore from Brain to Brain backup

Brain-to-brain backups are listed in the restore list command, together with any backups created on the local appliance.

The command always sorts local backups first, then all other backups (backups copied here by the brain-to-brain feature) in chronological order. The serial number of the originating brain is listed in the right-hand column.

Restoring from a brain-to-brain backup is done the same way as restoring from a locally-created backup:

  1. Use the restore list command to obtain the number of the desired backup.
  2. Use the restore run command to run the actual restore, for example:
    If not locally stored:
    restore run 3
    If the backup is locally stored:
    restore run --local 3
  3. Reassess the backup configuration on the new brain and ensure that the backups are configured as required for the new brain configuration.
Was this article helpful?
1 out of 1 found this helpful

Download PDF

0 Comments

Article is closed for comments.