Veritas NetBackup™ Read This First Guide for Secure Communications
- NetBackup Read This First for Secure Communications
- About secure communications in NetBackup
- How host ID-based certificates are deployed during installation
- How certificates are deployed on hosts during upgrades
- How secure communication works with master server cluster nodes
- When an authorization token is required during certificate deployment
- Why do you need to map host names (or IP addresses) to host IDs
- How to reset host attributes or host communication status
- What has changed for catalog recovery
- What has changed with Auto Image Replication
- How the hosts with revoked certificates work
- How communication happens when a host cannot directly connect to the master server
- Are security certificates backed up
- How communication with legacy media servers happens in the case of cloud configuration
- How NetBackup 8.1 hosts communicate with NetBackup 8.0 and earlier hosts
- Communication failure scenarios
- Secure communication support for other hosts in NetBackup domain
How secure communication works with master server cluster nodes
Review the following scenarios about certificate deployment if you have a clustered master server:
In the case of fresh NetBackup installation, the certificate on an active node is deployed automatically. You must manually deploy certificates on all inactive nodes.
In the case of disaster recovery, certificates for active and inactive nodes are not recovered. After you install NetBackup in a disaster recovery mode after a disaster, you must manually deploy certificates on all nodes using a reissue token.
In the case of upgrade, active or inactive nodes may already have a certificate. You can verify whether a cluster node has a certificate or not by viewing the certificate details with the nbcertcmd -listCertDetails command.
Note:
If you have configured NetBackup Access Control (NBAC) or Enhanced Auditing (EA) on a master server cluster node, you also need to manually deploy host name-based certificates on all nodes.
In a cluster setup, the same virtual name is used across multiple cluster nodes. Therefore, the virtual name should be mapped with all associated cluster nodes.