How to maintain fault group with copy cluster?

Copy cluster expects the same number of nodes, node_names, and target database name on the target system. It wont work if even one of these is different.
https://www.vertica.com/kb/Copying-Data-Between-Similar-Vertica-Clusters/Content/BestPractices/Copying-Data-Between-Similar-Vertica-Clusters.htm

Once these conditions are met, copy cluster will use rsync to ensure both source and target cluster are an exact copy.

Note, fault group configuration will carry thru, since the node names will (are required) to be identical

Thank you skeswani,
The only differences are the IP address and the location of the nodes in the racks.
So copy cluster will work but probably will not respect target fault group configuration. So the question remain.

BTW, If the solution will be to copy one schema at a time using vbr for the whole ~350TB, do we have an automatic way to copy all the other DB items ?
I.e. users, grants, parameters, UDx etc.

I use the attached script will create a database view that will reveal the DDL statements needed to re-create users and grants.

By default it will respect source cluster fault groups. (i.e at the end target will be identical to source in every respect including fault groups)
If you want a entirely different fault group mapping, then it requires re-balancing data, this a expensive operation and not in the scope for copy cluster.

When copying tables, you are assuming two entirely different clusters.

With regard to dependent objects it become tricky, and there no single answer.
There is dependency tree.
If I copy a table should i be copying the User or User Password?, sequences?
UDx's may have the same name but different implementations in the two clusters.

So to answer you question.
1. Yes, it will copy all data related dependent objects, projections, cols etc.
2. It will validate the existence of other objects like sequences, UDx's
3. If will not copy Users and Grants.

So with respect to object level copy the data and corresponding dependencies are moved. For other items like USers, etc. you can export from one db use a export command and import it into the target database. (standard DDL should be able to achieve this)

Thank you Skeswani and Jim.
For my understanding copy cluster can not handle different fault group mapping.
It is a common situation to have different IP addresses mapping in the DR site.
Re-balancing huge database is a nightmare customers want to avoid.
Export/Import is not relevant for huge databases.
So the suggested workaround from performance perspective is vbr per schema.
That's why the question came up and maybe worth a Jira.

BTW: different IP is expected and will work. Clearly you cannot have rsycn between same IP. I believe we correctly handle the IP difference. (i.e. there is no expectation that source and target clusters have same IP. This would be a violation of network routing :-)

With regard to Fault Groups.....

Say your source is
group1 ( node1, node2, node3, node4, node5)
group2 ( node6, node7, node8, node9)

the target
group1( node1, node2, node3, node4)
group2( node5, node6, node7,node8,node9)

the above case is not a problem for copy cluster. since the shape of the fault groups is identical. This can be trivially achieved by renaming the nodes and groups on the target cluster to look like the source cluster

The problem is you cannot have a target that looks like this
group1 ( node1, node2, node3)
group2
group 2a (node4, node5, node6)
group 2b (node7,node8 , node9)