Follow

Restore back up to new brain from old brain

Introduction to restoring a back up to a new brain

Backups taken by the automated backup and brain-to-brain backup features may be restored from the command line interface (CLI) on the brain after logging in to the serial console or using SSH.  In both cases the default credentials may be found in this article.

In the event a brain needs to be replaced because of any reason, one step in the process should be restoring a recent backup from the brain being removed from the network. This particular article will focus on establishing a target brain to copy a backup from a source brain. We cover setting this up for regular backups in greater detail in our article Brain to Brain Automated Backups, but this article focuses specifically on one-time backups for the purposes of migrating brains.

This article assumes that the restore is coming from a brain, but the restore can first be copied to an SFTP endpoint and from that point on, the source brain will be replaced functionally by the SFTP endpoint.

Preparing the network

There are two ports that need to be able to communicate bidirectionally between the source and the target; port 22 for SSH and port 443 for TLS encrypted communication. 

mceclip0.png

As mentioned in the introduction, if you are using an SFTP server, you would replace the source brain as this SFTP server's details.

Configuring the source brain to copy the restore to the target

  • First, we need to access the target server. From the vectra user SSH login, we need to get the backup token, allow connection from source brain and enable backup:
> token show
> backup accept-from-brains [ hosts ] [ --all-hosts ]
> backup enable
  • Next, we need to configure the source brain to know how to send the back up to the target brain:
> backup configure-target --enable-brain --target-brain <Hostname or IP of target> --brain-key <target key>
  • Now we can test the backup configuration from the source with this simple command:
> backup test
  • If unsuccessful, you will need to confirm the variables associated with the target along with connectivity over port 22 and 443. If successful, you will see output like this:
Testing backup copy to file server...
Test copy to file server successful.
Check for a file named <dynamic temporary file> on the target. 

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

Finalize the restore on the target brain

  • First, you will need to run a fresh backup from the source brain. You can force a backup to begin with 
> backup run
  • The time it takes to run the backup can have several variables that can have an impact.
    • Amount of data to be backed up
    • Network latency between brains
    • Unforeseen variables
  • Once the backup completes, you will need to begin to unpair existing sensors from the source brain. 
  • Target brain checks if any backups are available every hour at the top of the hour and once a suitable backup is identified it will pull the backup file.
  • Next, we need to make sure our backup is available on the target to restore upon. We will do that with this command:
> restore list
Backup|Date |Origin Serial Number
1 20YY-MM-DD 00:00:00 S00000000000000
  • If no backups are listed, something in the process did not work as expected. You may need to contact Vectra support if so.
  • Finally, we will kick off the restore:
> restore run [--local backup#]

Final Steps

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. 

There may be special steps needed to connect Recall or Stream to the new brain. If you have any trouble, don't hesitate to contact Vectra with any questions you may have. 

Was this article helpful?
1 out of 1 found this helpful

Download PDF

Have more questions? Submit a request

0 Comments

Article is closed for comments.