Can you restore a schema backup to another cluster?

For the question about backing up schemas, the following could be helpful -
http://my.vertica.com/docs/7.0.x/HTML/index.htm#Authoring/AdministratorsGuide/BackupRestore/CreatingObjectLevelBackups.htm?Highlight=object%20backup

Hi Raul,
Thanks for the quick reply. I had already read that doc but it does not answer my question.
Nor does this restore doc http://my.vertica.com/docs/7.0.x/HTML/Content/Authoring/AdministratorsGuide/BackupRestore/RestoringO... 
Since it only refers to restoring to the *same* cluster that the schema backup was taken from ("To restore an object-level backup to the database from which it was taken"...).
I am asking 2 questions.
1. Can I restore a *schema* backup to a cluster that is not the cluster the database was taken from?
2. Does the secondary/restore cluster have to be the exact same number of nodes as the source/backup cluster?
Stated differently; If I backup a schema on clusterA that has 4 nodes. Can I restore the schema backup to ClusterB that has (more) 8 nodes?
3rd question for extra points ;-) Does the schema restore require the exact same database name as the backup cluster database name it came from?
Mahalo, - JackG

The following provides the answer, which is, it will fail -
http://my.vertica.com/docs/7.0.x/HTML/index.htm#Authoring/AdministratorsGuide/BackupRestore/RestoringObjectLevelBackups.htm?Highlight=restore
See the section - Restoring Objects to a Changed Cluster Topology

Thanks Raul, If we had the same number of nodes between the source and destination cluster can we find a way around the IP addresses needing to be the same? That seems to be the limiting factor.
It would be nice if we had a copy schema equivalent to copy cluster (database).
Mahalo, - JackG

Hi Jack,

As Raul pointed out, we don't have this functionality currently in Vertica.

To answer your latest question, we can't bypass the need to same IPs as well. The the backup can oly be restored to the cluster where it was taken.
If you are looking to migrate data to another DB running on another cluster, I would suggest trying Vertica's Export/Import feature.

Administrator's Guide --> Copying and Exporting Data --> Exporting Data

https://my.vertica.com/docs/7.0.x/HTML/index.htm#Authoring/AdministratorsGuide/CopyExportData/ExportingData.htm?Highlight=Export

You will have to do this table wise, but it should fulfill your requirement.


Thanks,
Pravesh

Thanks Pravesh,
Do have any further tips on increasing throughput using Exporting/Copying with 'CompressNetworkData'?
And/or how this performs relative to alternatives like "Parallel Load Streams"
Or loading data located on multiple nodes with a single copy statement? 
Mahalo, - JackG

Jack,

CompressNetworkData would be a good thing. However, please ensure that this parameter is set same on both the clusters (source and target).
We had a bug in Vertica v6.0 where target cluster would crash if we tried to import from other database and if the parameter was set differently on other cluster. This bug was fixed ib v6.1.


Export/Import throughput would always be lower than Parallel load streams as Export/Import implementation isn't parallel as yet.

Thanks.

gtk, thanks Pravesh and Raul. Cheers.