The 5.3.0 release includes some backend changes to the backup systems included to resolve some previous issues and pre-empt future functionality.
As part of these changes, some customer appliances suffered the effects of a race-condition causing the regeneration of the RSA authentication key associated with the backup configuration.
This key is used by the backup system to authenticate the brain appliance against the SCP/SFTP server used to store the backup. The regeneration of this key causes the authentication against that server to fail and, while the backup itself completes normally, the backup copy to the SCP/SFTP server fails and therefore the backup is not saved externally.
Customers affected by this issue who have external Syslog configured for their appliances will see a copy error on their Syslog server. Vectra recommends that customers without Syslog configured should take this opportunity to configure external Syslog for their brain appliance.
To confirm whether you are affected by this issue you will need to compare the SSH public key presented in the Vectra CLI to the SSH public key saved in the authorized_keys file on the SCP/SFTP server.
The Vectra SSH public key may be viewed using the 'backup show' command available when logging in to the SSH CLI using the 'vectra' user:
vscli > backup show
Backups Enabled: True
Copy Mode: sftp
Copy To Brain: False
Public Key Data: [SSHpublickey]
Scheduled Backup Day: Sunday
Scheduled Backup Hour: 8
The SSH public key presented above should be compared to and replace the SSH public key in the authorized_keys file on the SCP/SFTP server.
Once updated the backup copy may be tested using the 'backup test' command and, if appropriate, an immediate backup may be triggered using the 'backup run' command.