Providing meaningful names for the objects you create in Protector is one of the best ways to ensure that your data protection strategy is understandable, manageable and maintainable. The following guidelines will help you achieve this:
- Adopt a naming convention that results in similar concepts being listed together when sorted alphabetically. For example VSPCorporate and VSPUKOffice are preferable to CorpVSP and UKOfficeVSP.
- In general, Protector names should use nouns to describe objects and verbs to describe operations that are specific to the business processes in which they are used rather than Protector terminology.
- Names should be unique enough so as to avoid misunderstanding and confusion.
For example: Site1Broadstone and Site11London are preferable to Site1 and Site11.
- Node names should describe the node's role in the organization and possibly its location. Avoid describing its type or other generic attributes that can be determined from the Node Details.
For example: VSPTexasSalesCorp is preferable to PrimaryVSPG400.
- Node Group names should describe the node group's role in the organization and possibly its location. Avoid describing its type or other generic attributes that can be determined from the Node Group Details.
For example: ClusterDbLegal is preferable to OracleRAC.
- Policy names should describe what the policy does,
specifically in the context of the organization's data protection strategy. Avoid
describing its classifications, filters, operations, scheduling or other generic
attributes that can be determined from the Policy Details.
For example: OracleDRMajorHeadOffice is preferable to UniversalRepOraclePolicy.
- Operation names should describe what the operation does, specifically within the context of the policy in which it is used. Avoid describing its type, scheduling or other generic attributes that can be determined from the Policy Operation Details.
For example: ReplicateLocal and ReplicateOffsite are preferable to Replicate1 and Replicate2.
- Data Flow names should describe the data protection policy
that is being implemented, specifically within the context of the organization's data
protection strategy. Avoid describing attributes that can be determined from the Data Flows Inventory, Data Flow Details or Monitor Details.
For example: OracleFailOverToSubOffice is preferable to ReplicateOracleDataFlow.
- Mover labels should describe the purpose of the mover
and/or the association between the nodes it connects. Avoid describing the operation name
or operation type since these already appear in the Data Flow Details.
For example: Fine Grain Protection is preferable to Weekly backup.
- Schedule names should describe the purpose of the schedule. If the schedule is related to a specific policy then name it after that policy. Avoid describing its type or other attributes that can be determined from the Schedule Details.
For example: BackupWindowOvernight is preferable to Weekdays10PMTo6AM.
Note: The naming conventions used elsewhere in this guide are designed to aid understanding of Protector concepts, tasks and workflows. They do not represent good naming conventions when using the product in a production environment.