Eon Mode database requirements

Eon Mode databases perform the same backup and restore operations as Enterprise Mode databases. Additional requirements pertain to Eon Mode because it uses a different architecture.

Cloud storage requirements

Eon Mode databases must be backed up to supported cloud storage locations. The following [CloudStorage] configuration parameters must be set:

• cloud_storage_backup_path

• cloud_storage_backup_file_system_path

A backup path is valid for one database only. You cannot use the same path to store backups for multiple databases.

Eon Mode databases that use S3-compatible on-premises cloud storage can back up to Amazon Web Services (AWS) S3.

Cloud storage access

In addition to having access to the cloud storage bucket used for the database's communal storage, you must have access to the cloud storage backup location. Verify that the credential you use to access communal storage also has access to the backup location. For more information about configuring cloud storage access for Vertica, see Configuring cloud storage backups.

Eon on-premises and private cloud storage

If an Eon database runs on-premises, then communal storage is not on AWS but on another storage platform that uses the S3 or GS protocol. This means there can be two endpoints and two sets of credentials, depending on where you back up. This additional information is stored in environment variables, and not in vbr configuration parameters.

Backups of Eon Mode on-premises databases do not support AWS IAM profiles.

HDFS on-premises storage

To back up an Eon Mode database that uses HDFS on-premises storage, the communal storage and backup location must use the same HDFS credentials and domain. All vbr operations are supported, except copycluster.

Vertica supports Kerberos authentication, High Availability Name Node, and wire encryption for vbr operations. Vertica does not support at-rest encryption for Hadoop storage.

For details, see Configuring backups to and from HDFS.

Database restore requirements

When restoring a backup of an Eon Mode database, the restore database must satisfy the following requirements:

• Share the same name as the backup database.
• Have at least as many nodes as the primary subcluster(s) in the backup database.
• Have the same node names as the nodes of the backup database.
• Use the same catalog directory location as the backup database.
• Use the same port numbers as the backup database.
• For object-level restore, the target namespace in the restore database and the objects' namespace in the source database must have the same shard count, shard boundaries, and node subscriptions. For details, see object-level tasks with multiple namespaces.

You can restore a full or object backup that was taken from a database with primary and secondary subclusters to the primary subclusters in the target database. The database can have only primary subclusters, or it can also have any number of secondary subclusters. Secondary subclusters do not need to match the backup database. The same is true for replicating a database; only the primary subclusters are required. The requirements are similar to those for Reviving an Eon Mode database cluster.

Use the [Mapping] section in the configuration file to specify the mappings for the primary subcluster.

Object-level tasks with multiple namespaces

Eon Mode databases group schemas and tables into one or more namespaces. By default, Eon databases contain only one namespace, default_namespace, which is created during database creation. Unless you have created additional namespaces, the default_namespace contains all schemas and tables. If you do not specify the namespace of an object, vbr assumes the object belongs to the default_namespace. Full database vbr tasks are unaffected by the number of namespaces.

For object-level backups, you can specify the included objects in the objects parameter of your vbr configuration file. For example, to create an object-level backup of all objects in the orders and customers schemas in the store_1 namespace, add the following lines to your configuration file:

objects = .store_1.orders*, .store_1.customers.*

Alternatively, you can specify the included and excluded objects using the includeObjects and excludeObjects parameters. If you set these parameters, the objects parameter must be empty.

For object-level restore and replicate vbr tasks, you can optionally specify a target namespace with the --target-namespace command line argument. This is the namespace to which the objects are restored or replicated in the target cluster. The action that vbr performs depends on whether you provide a value for this argument:

• No value: vbr attempts to restore or replicate the objects to a namespace with the same name as the objects' source namespace. If no such namespace exists in the target cluster, or its shard counts differs from the source namespace, the task fails.
• Target namespace provided: vbr attempts to restore or replicate the objects to the specified namespace in the target cluster. The namespace must already exist in the target cluster and have the same shard count, shard boundaries, and node subscriptions as the object's source namespace.

You can specify how restore operations handle duplicate objects with objectRestoreMode parameter in the vbr configuration file.

The following command restores the store_1.orders schema to the store_2 namespace of the target cluster:

$ vbr --task restore --config-file=db.ini --restore-objects=.store_1.orders.* --target-namespace=store_2