Vertica Analytics Platform Version 9.2.x Documentation

[Mapping]

You have one [Mapping] section for all of the nodes in your database cluster. The section must appear in your configuration file because it specifies all the database nodes being included in the backup. It also includes the backup host and directory for each node. If you have objects being replicated to an alternate database, the [Mapping] section also maps the target database nodes to the source database backup locations.

If you edit an existing configuration file to add a Mapping in the current style, you must combine information from all existing Mappings into the new section.

The [S3] and [Mapping] configuration sections are mutually exclusive. If you include both, your backup fails with the error message "Config has conflicting sections (Mapping, S3), specify only one of them."

Parameter Default Description

backupHost

None

Indicates the target host name or IP address on which to store this node's backup. The backupHost name is different from dbNode. The copycluster command uses this value to identify the target database node host name.

Performance Consideration:

Although supported, backups to an NFS host may have poor performance, particularly on networks shared with rsync operations.

backupDir

None

Identifies the full path to the directory on the backup host or node where the backup will be stored.

Directory Requirements:

  • Must already exist when you run vbr with the --task backup option
  • Must be writable by the user account used to run vbr.
  • Must be unique to the database you are backing up. Multiple databases cannot share the same backup directory.
  • The file system at this location must support fcntl lockf file locking.

dbNode

None

The name of the database node, as recognized by Vertica. This value is not the node's host name, but rather the name Vertica uses internally to identify the node, usually in the form of:

v_node00x

To find database node names in your cluster, query the node_name column of the NODES system table.

Map to the localhost

vbr does not support the special localhost name as a backup host. To back up a database node to its own disk, use empty square brackets for the hostname in the [Mapping] section of the configuration file.

[Mapping]
NodeName = []:/backup/path

Your mapping section should resemble this example:

[Mapping]
v_exampledb_node0001 = destination_host1.example
v_exampledb_node0002 = destination_host2.example
v_exampledb_node0003 = destination_host3.example
v_exampledb_node0004 = destination_host4.example

Map to the Same Database

The following example shows how you can specify a Mapping section that indicates a single node to be backed up (v_vmart_node0001). The node is assigned to the backup host (v_srv01), and the backup directory (/home/dbadmin/backups). Although you are backing up a single node cluster, and the backup host and the database node are the same system, you specify them differently.

Specify the backup host and directory, using a colon (:) as a separator: 

[Mapping]
v_vmart_node0001 = srv01:/home/dbadmin/backups

Although the configuration file [Mapping] section no longer uses named parameters, you still use the elements of the simplified format continue to represent the following parameters:  

dbNode = backupHost:backupDir

Map to an Alternate Database

Before you can replicate objects to an alternate database, you must also create a [NodeMapping] section in your vbr configuration file. The NodeMapping section points source nodes to their target database nodes.

Restore an alternate database, by adding mapping information in the following form:

[Mapping]
targetNode: sourceDBNode_backuphost:sourceDB_backuppath

Your mapping section should resemble this example:

[Mapping]
v_sec_node0001 = pri_bsrv01:/archive/backup
v_sec_node0002 = pri_bsrv02:/archive/backup
v_sec_node0003 = pri_bsrv03:/archive/backup