take a backup on one cluster server and restore it on the other

This is documented, https://my.vertica.com/docs/6.1.x/HTML/index.htm#16026.htm

To restore a full database snapshot, you must ensure that:

• The database is down. You cannot restore a full snapshot when the database is running.
• All of the backup hosts are up and available.
• The backup directory exists and contains the snapshots from which to restore.
• The cluster to which you are restoring the backup has the same number of hosts as the one used to create the snapshot. The node names and the IP addresses must also be identical.
• The database you are restoring already exists on the cluster to which you are restoring data. The database can be completely empty without any data or schema. As long as the database name matches the name in the snapshot, and all of the node names match the names of the nodes, you can restore to it.

In direct answer to your question, Vertica does not currently support restore of a backup to an alternate cluster. The backup is intended to be used to restore the database to the same cluster the backup was taken from. There are some object id dependencies as you saw in the errors.

There is an outstanding feature request ver-19451 for the capability to restore to an alternate cluster but it is not yet targeted. The vbr.py copdatabase is the only method we have of making a duplicate of the source cluster on a target cluster with different host names and ips. There are some requirements outlined in the docs. See "Copying the Database to Another Cluster" under the Backing up and Restoring section of the Admin Guide.

Steve,

That answers my question as I was looking for restoring to the machine with different ip and hostname.

However, in few forums i was reading about changing the catalog.ctlg file to have the new ipaddress and then to restore.

I tried for full database backup and it seemed to be working but at the end once the whole database files are copied, its saying it is failing with SIGINT.

Copying...

[==================================================] 100%^

11776: vbr client subproc on 15.224.232.116 terminates with returncode 2. Details in vbr_v_verlabqa01_node0002_client.log on that host.

cancelled by SIGINT

why is this the case? Also is it safe to follow this procedure? and is it possible to do the same for schema restore too?

Thanks
Saumya

The short answer is that any posting found where you edit files is an undocumented and unsupported method, and subject to not working in all versions. E.g. the entire catalog structure changed in v6 so a pre v6 process would not work against a v6 or later database and vice versa.

The only suggestion on trying to resolve the error would be either look in the log file noted for hints or run vbr.py with a higher debug level. vbr.py has a --debug arg you can pass. The default is 0. If you run it with --debug 3 it may provide additional info on what's failed.

Schema restore would definitely not work using this type of process. There are additional requirements for object level backups as the backup is a minimal one with lots of object id pointers, and without the base backup the momento refs would not exist to reconstruct the objects in the object level backup.

Thanks Steve for the information.

@Saumya
 I'm not sure if i'm stuck with a similar issue.
I'm planning to take a full db,schema level and object level backups individually from a single node vertica 6.1.1  and restore it onto a similarly configured machine with a  which runs vertica 6.1.1 with single node.

As per Steve in the above post  Schema level restore isn't possible.
Do you have a work around for my case?

Thanks,
Sunil