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 target database must satisfy the following requirements:

• Share the same name as the source database.
• Have at least as many nodes as the primary subcluster(s) in the source database.
• Have the same node names as the nodes of the source database.
• Use the same catalog directory location as the source database.
• Use the same port numbers as the source database.
• For object-level restore, if you restore to an existing target namespace, the target namespace and the objects' source namespace 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 use the --target-namespace argument to specify the namespace to which the objects are restored or replicated.

vbr behaves differently depending on whether the target namespace exists:

• Exists: vbr attempts to restore or replicate the objects to the existing namespace, which must have the same shard count, shard boundaries, and node subscriptions as the source namespace. If these conditions are not met, the vbr task fails.
• Nonexistent: vbr creates a namespace in the target database with the name specified in --target-namespace and the shard count of the source namespace, and then replicates or restores the objects to that namespace.

If no target namespace is specified, vbr attempts to restore or replicate objects to a namespace with the same name as the 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 of the source database to the store_2 namespace in the target database:

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

If no target namespace is specified, vbr attempts to restore the objects to a namespace with the same name as the source namespace. For example, you can omit the --target-namespace=store_1 argument when restoring the store_1.orders schema to the store_1 namespace:

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

Restoring a database with multiple communal storage locations

You can back up and restore Eon Mode databases that have multiple communal storage locations. Both object-level and full database restore operations are supported:

• Full database restore: the result of the restore operation depends on whether you are restoring to the same communal storage locations from which you performed the backup:

  • Same communal storage locations: vbr attempts to copy all data to the communal storage locations from which they were backed up. If a storage location has been dropped since the backup was taken, the restore operation attempts to reinstate the dropped location before restoring the data. If the dropped storage location cannot be reinstated, its associated data is copied to the main communal storage location.

  • Different communal storage location: all data is copied to the communal storage location specified in the vbr configuration file. Regardless of how many communal storage locations existed before the restore, there will be only one communal storage location after the full restore.

• Object restore: the location to which an object is restored depends on whether it has an existing storage policy in the target database:

  • Storage policy: vbr restores the object to the communal storage location specified by the object's highest priority storage policy, which is determined by the following hierarchy, listed from highest priority to lowest:

    1. Table-level policy
    2. Schema-level policy
    3. Database-level policy When the communal storage location specified by the highest priority policy does not exist, vbr attempts to execute the policy with the next highest priority. If none of the policies are valid, the object is restored to the main communal storage location.

  • No storage policy: the object is copied to the main communal storage location.

For details on creating and configuring storage policies for multiple communal storage locations, see Configuring your Vertica cluster for Eon Mode.