Ransomware attackers specifically target and attempt to destroy backup systems to increase the probability of payment. Hardening your system is critical. Please ensure you have reviewed your platform security using the Security Hardening Checklist
Cohesity

COHESITY Documentation

Explore our documentation to get started, discover products & new features, access troubleshooting guides, register sources, platforms support.

Products
Data Security Alliance
Visit Cohesity.com
Demos
Support
Blogs
Developers
Partner Portals
Cohesity Community
© 2026 Cohesity, Inc. All Rights Reserved.
Terms of Use|
Privacy Policy|
Legal|
  1. Home
  2. NetBackup™ Security and Encryption Guide
  3. Section II. Encryption of data-in-transit
  4. NetBackup CA and NetBackup certificates
  5. About host management
  6. Adding shared or cluster mappings
  7. About shared or cluster mapping scenarios
NetBackup™ Security and Encryption Guide

About shared or cluster mapping scenarios

Host ID to host name mappings can be shared across multiple hosts in the following scenarios:

  • If multiple hosts from different domains use the same host name

  • In a cluster setup where the same virtual name is used by multiple cluster nodes

However, in a scenario where the associated hosts do not have the same communication status (some are 8.0 or earlier and can communicate insecurely and some are 8.1 or later and communicate securely), communication may fail.

See Add or Remove Host Mappings dialog box.

Scenario 1 - If multiple hosts from different domains use the same host name

Consider the following example:

  • Host1 - abc.secure.domain1.com, version - 8.1, policy - P1

  • Host2 - abc.insecure.domain2.com, version - 7.7.3, policy - P2

  • Host1 and Host 2 use the same name - abc - as their host name. Security Administrator adds abc as a shared mapping for Host2.

    See Adding shared or cluster mappings.

  • Insecure communication with 8.0 and earlier hosts is enabled.

    See About insecure communication with 8.0 and earlier hosts.

  • When Host2 initiates communication with another host, the primary server validates the communication status of host2 (which is insecure), which is different than Host1 (which is secure). Because both hosts use the same host name, but their communication status do not match, the communication with Host2 fails.

  • Recommendation - Host2 should be upgraded to 8.1 or later.

Scenario 2 - In a cluster setup where the same virtual name is used by multiple cluster nodes

Consider the following example:

  • Host1 - abc.secure.domain1.com, active cluster node, version - 8.1

  • Host2 - abc.secure.domain1.com, inactive cluster node, version - 8.0

  • Host1 and Host2 use the same virtual name that is abc. Security Administrator adds abc as a shared or cluster mapping for Host2.

    See Adding shared or cluster mappings.

  • Insecure communication with 8.0 and earlier hosts is enabled.

    See About insecure communication with 8.0 and earlier hosts.

  • Host1 fails over to Host2. The primary server validates the communication status of host2 (that is insecure), which is different than Host1 (that is secure). Because communication status for both hosts do not match, the communication with Host2 fails.

  • Recommendation - Host2 should be upgraded to 8.1.

  • Workaround - Delete the host ID-to-host name mapping abc for Host1. In case of shared mapping, if the associated hosts do not have the same communication status (secure), communication fails for the host that has insecure communication status.

Feedback

Was this page helpful?
Previous

Adding shared or cluster mappings

Next

Add Shared or Cluster Mappings dialog box

Feedback

Was this page helpful?