OpenText Analytics Database 26.2.x – Backing up and restoring the database

Admin: Common use cases

Mon, 01 Jan 0001 00:00:00 +0000

You can use vbr to perform many tasks related to backup and restore. The vbr reference describes all of the tasks in detail. This section summarizes common use cases. For each of these cases, there are additional requirements not covered here. Be sure to read the linked topics for details.

This is not a complete list of Backup/Restore capabilities.

Routine backups in Enterprise Mode

A full backup stores a copy of your data in another location—ideally a location that is separated from your database location, such as on different hardware or in the cloud. You give the backup a name (the snapshot name), which allows you to have different backups and backup types without interference. In your configuration file, you can map database nodes to backup locations and set some other parameters.

Before your first backup, run the vbr init task.

Use the vbr backup task to perform a full backup. The External full backup/restore example provides a starting point for your configuration. For complete documentation of full backups, see Creating full backups.

Routine backups in Eon Mode

For the most part, backups in Eon Mode work the same way as backups in Enterprise Mode. Eon Mode has some additional requirements described in Eon Mode database requirements, and some configuration parameters are different for backups to cloud storage. You can back up or restore Eon Mode databases that run in the cloud or on-premises using a supported cloud storage location.

Use the vbr backup task to perform a full backup. The Backup/restore to cloud storage example provides a starting point for your configuration. For complete documentation of full backups, see Creating full backups.

Checkpoint backups: backing up before a major operation

It is a good idea to back up your database before performing destructive operations such as dropping tables, or before major operations such as upgrading OpenText™ Analytics Database to a new version.

You can perform a regular full backup for this purpose, but a faster way is to create a hard-link local backup. This kind of backup copies your catalog and links your data files to another location on the local file system on each node. (You can also do a hard-link backup of specific objects rather than the whole database.) A hard-link local backup does not provide the same protection as a backup stored externally. For example, it does not protect you from local system failures. However, for a backup that you expect to need only temporarily, a hard-link local backup is an expedient option. Do not use hard-link local backups as substitutes for regular backups to other nodes.

Hard-link backups use the same vbr backup task as other backups, but with a different configuration. The Full hard-link backup/restore example provides a starting point for your configuration. See Creating hard-link local backups for more information.

Restoring selected objects

Sometimes you need to restore specific objects, such as a table you dropped, rather than the entire database. You can restore individual tables or schemas from any backup that contains them, whether a full backup or an object backup.

Use the vbr restore task and the --restore-objects parameter to specify what to restore. Usually you use the same configuration file that you used to create the backup. See Restoring individual objects for more information.

Restoring an entire database

You can restore both Enterprise Mode and Eon Mode databases from complete backups. You cannot use restore to change the mode of your database. In Eon Mode, you can restore to the primary subcluster without regard to secondary subclusters.

Use the vbr restore task to restore a database. As when restoring selected objects, you usually use the same configuration file that you used to create the backup. See Restoring a database from a full backup and Restoring hard-link local backups for more information.

Copying a cluster

You might need to copy a database to another cluster of computers, such as when you are promoting a database from a staging environment to production. Copying a database to another cluster is essentially a simultaneous backup and restore operation. The data is backed up from the source database cluster and restored to the destination cluster in a single operation.

Use the vbr copycluster task to copy a cluster. The Database copy to an alternate cluster example provides a starting point for your configuration. See Copying the database to another cluster for more information.

Replicating selected objects to another database

You might want to replicate specific tables or schemas from one database to another. For example, you might do this to copy data from a production database to a test database to investigate a problem in isolation. Another example is when you complete a large data load in one database, replication to another database might be more efficient than repeating the load operation in the other database.

Use the vbr replicate task to replicate objects. You specify the objects to replicate in the configuration file. The Object replication to an alternate database example provides a starting point for your configuration. See Replicating objects to another database cluster for more information.

Admin: Sample vbr configuration files

Mon, 01 Jan 0001 00:00:00 +0000

The vbr utility uses configuration files to provide the information it needs to back up and restore a full or object-level backup or copy a cluster. No default configuration file exists. You must always specify a configuration file with the vbr command.

OpenText™ Analytics Database includes sample configuration files that you can copy, edit, and deploy for various vbr tasks. These files are automatically installed at:

/opt/vertica/share/vbr/example_configs

Admin: Eon Mode database requirements

Mon, 01 Jan 0001 00:00:00 +0000

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.

Eon Mode databases also support saving in-db restore points, which are copy-free backups that enable you to roll back a database to a previous state. Unlike vbr-based backups, restore points are stored in-database and do not require additional data copies to be stored externally. However, because restore points are in-database, they are lost if the database's communal storage is compromised. For more information about restore points, see Revive an Eon DB.

Note

These requirements are for cloud storage locations listed in Backing up and restoring the database, and on-premises with communal storage on HDFS.

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 OpenText™ Analytics Database, see Configuring cloud storage backups.

Note

While an AWS backup location can be in a different region, backup and restore operations across different S3 regions are incompatible with virtual private cloud (VPC) endpoints.

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.

OpenText™ Analytics Database supports Kerberos authentication, High Availability Name Node, and wire encryption for vbr operations. OpenText™ Analytics Database 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 Revive with communal storage.

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.

Important

For vbr tasks, namespaces are prefixed with a period. For example, .n.s.t refers to table t in schema s in namespace n.

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.

Admin: Requirements for backing up and restoring HDFS storage locations

Mon, 01 Jan 0001 00:00:00 +0000

There are several considerations for backing up and restoring HDFS storage locations:

The HDFS directory for the storage location must have snapshotting enabled. You can either directly configure this yourself or enable the database administrator’s Hadoop account to do it for you automatically. See Hadoop configuration for backup and restore for more information.
If the Hadoop cluster uses Kerberos, OpenText™ Analytics Database nodes must have access to certain Hadoop configuration files. See Configuring Kerberos below.
To restore an HDFS storage location, your database cluster must be able to run the Hadoop distcp command. See Configuring distcp on a database cluster below.
HDFS storage locations do not support object-level backups. You must perform a full database backup to back up the data in your HDFS storage locations.
Data in an HDFS storage location is backed up to HDFS. This backup guards against accidental deletion or corruption of data. It does not prevent data loss in the case of a catastrophic failure of the entire Hadoop cluster. To prevent data loss, you must have a backup and disaster recovery plan for your Hadoop cluster.

Data stored on the Linux native file system is still backed up to the location you specify in the backup configuration file. It and the data in HDFS storage locations are handled separately by the vbr backup script.

Configuring Kerberos

If HDFS uses Kerberos, then to back up your HDFS storage locations you must take the following additional steps:

Grant Hadoop superuser privileges to the Kerberos principals for each database node.
Copy Hadoop configuration files to your database nodes as explained in Accessing Hadoop Configuration Files. The database needs access to core-site.xml, hdfs-site.xml, and yarn-site.xml for backup and restore. If your database nodes are co-located on HDFS nodes, these files are already present.
Set the HadoopConfDir parameter to the location of the directory containing these files. The value can be a path, if the files are in multiple directories. For example:
```
=> ALTER DATABASE exampledb SET HadoopConfDir = '/etc/hadoop/conf:/etc/hadoop/test';
```
All three configuration files must be present on this path on every database node.

If your database nodes are co-located on HDFS nodes and you are using Kerberos, you must also change some Hadoop configuration parameters. These changes are needed in order for restoring from backups to work. In yarn-site.xml on every database node, set the following parameters:

Parameter	Value
`yarn.resourcemanager.proxy-user-privileges.enabled`	true
`yarn.resourcemanager.proxyusers.*.groups`
`yarn.resourcemanager.proxyusers.*.hosts`
`yarn.resourcemanager.proxyusers.*.users`
`yarn.timeline-service.http-authentication.proxyusers.*.groups`
`yarn.timeline-service.http-authentication.proxyusers.*.hosts`
`yarn.timeline-service.http-authentication.proxyusers.*.users`

No changes are needed on HDFS nodes that are not also database nodes.

Configuring distcp on a database cluster

Your database cluster must be able to run the Hadoop distcp command to restore a backup of an HDFS storage location. The easiest way to enable your cluster to run this command is to install several Hadoop packages on each node. These packages must be from the same distribution and version of Hadoop that is running on your Hadoop cluster.

The steps you need to take depend on:

The distribution and version of Hadoop running on the Hadoop cluster containing your HDFS storage location.
The distribution of Linux running on your database cluster.

Note

Installing the Hadoop packages necessary to run distcp does not turn your database into a Hadoop cluster. This process installs just enough of the Hadoop support files on your cluster to run the distcp command. There is no additional overhead placed on the database cluster, aside from a small amount of additional disk space consumed by the Hadoop support files.

Configuration overview

The steps for configuring your database cluster to restore backups for HDFS storage location are:

If necessary, install and configure a Java runtime on the hosts in the database cluster.
Find the location of your Hadoop distribution's package repository.
Add the Hadoop distribution's package repository to the Linux package manager on all hosts in your cluster.
Install the necessary Hadoop packages on your database hosts.
Set two configuration parameters in your database related to Java and Hadoop.
Confirm that the Hadoop distcp command runs on your database hosts.

The following sections describe these steps in greater detail.

Installing a Java runtime

Your database cluster must have a Java Virtual Machine (JVM) installed to run the Hadoop distcp command. It already has a JVM installed if you have configured it to:

Execute user-defined extensions developed in Java. See Developing user-defined extensions (UDxs) for more information.
Access Hadoop data using the HCatalog Connector. See Using the HCatalog Connector for more information.

If your database has a JVM installed, verify that your Hadoop distribution supports it. See your Hadoop distribution's documentation to determine which JVMs it supports.

If the JVM installed on your database cluster is not supported by your Hadoop distribution you must uninstall it. Then you must install a JVM that is supported by both OpenText™ Analytics Database and your Hadoop distribution. See SDKs for a list of the JVMs compatible with OpenText™ Analytics Database.

If your database cluster does not have a JVM (or its existing JVM is incompatible with your Hadoop distribution), follow the instructions in Installing the Java runtime on your database cluster.

Finding your Hadoop distribution's package repository

Many Hadoop distributions have their own installation system, such as Cloudera Manager or Ambari. However, they also support manual installation using native Linux packages such as RPM and .deb files. These package files are maintained in a repository. You can configure your database hosts to access this repository to download and install Hadoop packages.

Consult your Hadoop distribution's documentation to find the location of its Linux package repository. This information is often located in the portion of the documentation covering manual installation techniques.

Each Hadoop distribution maintains separate repositories for each of the major Linux package management systems. Find the specific repository for the Linux distribution running your database cluster. Be sure that the package repository that you select matches the version used by your Hadoop cluster.

Configuring database nodes to access the Hadoop Distribution’s package repository

Configure the nodes in your database cluster so they can access your Hadoop distribution's package repository. Your Hadoop distribution's documentation should explain how to add the repositories to your Linux platform. If the documentation does not explain how to add the repository to your packaging system, refer to your Linux distribution's documentation.

The steps you need to take depend on the package management system your Linux platform uses. Usually, the process involves:

Downloading a configuration file.
Adding the configuration file to the package management system's configuration directory.
For Debian-based Linux distributions, adding the Hadoop repository encryption key to the root account keyring.
Updating the package management system's index to have it discover new packages.

You must add the Hadoop repository to all hosts in your database cluster.

Installing the required Hadoop packages

After configuring the repository, you are ready to install the Hadoop packages. The packages you need to install are:

hadoop
hadoop-hdfs
hadoop-client

The names of the packages are usually the same across all Hadoop and Linux distributions. These packages often have additional dependencies. Always accept any additional packages that the Linux package manager asks to install.

To install these packages, use the package manager command for your Linux distribution. The package manager command you need to use depends on your Linux distribution:

On Red Hat and CentOS, the package manager command is yum.
On Debian and Ubuntu, the package manager command is apt-get.
On SUSE the package manager command is zypper.

Consult your Linux distribution's documentation for instructions on installing packages.

Setting configuration parameters

You must set two Hadoop configuration parameters to enable the database to restore HDFS data:

JavaBinaryForUDx is the path to the Java executable. You may have already set this value to use Java UDxs or the HCatalog Connector. You can find the path for the default Java executable from the Bash command shell using the command:
```
$ which java
```
HadoopHome is the directory that contains bin/hadoop (the bin directory containing the Hadoop executable file). The default value for this parameter is /usr. The default value is correct if your Hadoop executable is located at /usr/bin/hadoop.

The following example shows how to set and then review the values of these parameters:

=> ALTER DATABASE DEFAULT SET PARAMETER JavaBinaryForUDx = '/usr/bin/java';
=> SELECT current_value FROM configuration_parameters WHERE parameter_name = 'JavaBinaryForUDx';
 current_value
---------------
 /usr/bin/java
(1 row)
=> ALTER DATABASE DEFAULT SET HadoopHome = '/usr';
=> SELECT current_value FROM configuration_parameters WHERE parameter_name = 'HadoopHome';
 current_value
---------------
 /usr
(1 row)

You can also set the following parameters:

HadoopFSReadRetryTimeout and HadoopFSWriteRetryTimeout specify how long to wait before failing. The default value for each is 180 seconds. If you are confident that your file system will fail more quickly, you can improve performance by lowering these values.
HadoopFSReplication specifies the number of replicas HDFS makes. By default, the Hadoop client chooses this; the database uses the same value for all nodes.

Caution
Do not change this setting unless directed otherwise by the customer support team.
HadoopFSBlockSizeBytes is the block size to write to HDFS; larger files are divided into blocks of this size. The default is 64MB.

Confirming that distcp runs

After the packages are installed on all hosts in your cluster, your database should be able to run the Hadoop distcp command. To test it:

Log into any host in your cluster as the database superuser.
At the Bash shell, enter the command:
```
$ hadoop distcp
```

The command should print a message similar to the following:

usage: distcp OPTIONS [source_path...] <target_path>
              OPTIONS
 -async                 Should distcp execution be blocking
 -atomic                Commit all changes or none
 -bandwidth <arg>       Specify bandwidth per map in MB
 -delete                Delete from target, files missing in source
 -f <arg>               List of files that need to be copied
 -filelimit <arg>       (Deprecated!) Limit number of files copied to <= n
 -i                     Ignore failures during copy
 -log <arg>             Folder on DFS where distcp execution logs are
                        saved
 -m <arg>               Max number of concurrent maps to use for copy
 -mapredSslConf <arg>   Configuration for ssl config file, to use with
                        hftps://
 -overwrite             Choose to overwrite target files unconditionally,
                        even if they exist.
 -p <arg>               preserve status (rbugpc)(replication, block-size,
                        user, group, permission, checksum-type)
 -sizelimit <arg>       (Deprecated!) Limit number of files copied to <= n
                        bytes
 -skipcrccheck          Whether to skip CRC checks between source and
                        target paths.
 -strategy <arg>        Copy strategy to use. Default is dividing work
                        based on file sizes
 -tmp <arg>             Intermediate work path to be used for atomic
                        commit
 -update                Update target, copying only missingfiles or
                        directories

Repeat these steps on the other hosts in your database to verify that all of the hosts can run distcp.

Troubleshooting

If you cannot run the distcp command, try the following steps:

If Bash cannot find the hadoop command, you may need to manually add Hadoop's bin directory to the system search path. An alternative is to create a symbolic link in an existing directory in the search path (such as /usr/bin) to the hadoop binary.
Ensure the version of Java installed on your database cluster is compatible with your Hadoop distribution.
Review the Linux package installation tool's logs for errors. In some cases, packages may not be fully installed, or may not have been downloaded due to network issues.
Ensure that the database administrator account has permission to execute the hadoop command. You might need to add the account to a specific group in order to allow it to run the necessary commands.

Admin: Setting up backup locations

Mon, 01 Jan 0001 00:00:00 +0000

Important

Inadequate security on backups can compromise overall database security. Be sure to secure backup locations and strictly limit access to backups only to users who already have permissions to access all database data.

Full and object-level backups reside on backup hosts, the computer systems on which backups and archives are stored. On the backup hosts, OpenText™ Analytics Database saves backups in a specific backup location (directory).

You must set up your backup hosts before you can create backups.

The storage format type at your backup locations must support fcntl lockf (POSIX) file locking.

Admin: Creating backups

Mon, 01 Jan 0001 00:00:00 +0000

Important

You should perform full backups of your database regularly. You should also perform a full backup under the following circumstances:

Before…

Upgrading OpenText™ Analytics Database to another release.
Dropping a partition.
Adding, removing, or replacing nodes in the database cluster.

After…

Loading a large volume of data.
Adding, removing, or replacing nodes in the database cluster.
Recovering a cluster from a crash.

If…

The epoch of the latest backup predates the current ancient history mark.

Ideally, schedule ongoing backups to back up your data. You can run vbr from a cron job or other task scheduler.

You can also back up selected objects. Use object backups to supplement full backups, not to replace them. Backup types are described in Types of backups.

Running vbr does not affect active database applications. vbr supports creating backups while concurrently running applications that execute DML statements, including COPY, INSERT, UPDATE, DELETE, and SELECT.

Backup locations and contents

Full and object-level backups reside on backup hosts, the computer systems on which backups and archives are stored.

The database saves backups in a specific backup location, the directory on a backup host. This location can contain multiple backups, both full and object-level, including associated archives. The backups are also compatible, allowing you to restore any objects from a full database backup. Backup locations for Eon Mode databases must be on S3.

Note

OpenText does not recommend concurrent backups. If you must run multiple backups concurrently, use separate backup and temp directories for each. Having separate backup directories detracts from the advantage of sharing data among historical backups.

Before beginning a backup, you must prepare your backup locations using the vbr init task, as in the following example:

$ vbr -t init -c full_backup.ini

For more information about backup locations, see Setting up backup locations.

Backups contain all committed data for the backed-up objects as of the start time of the backup. Backups do not contain uncommitted data or data committed during the backup. Backups do not delay mergeout or load activity.

Backing up HDFS storage locations

If your database cluster uses HDFS storage locations, you must do some additional configuration before you can perform backups. See Requirements for backing up and restoring HDFS storage locations.

HDFS storage locations support only full backup and restore. You cannot perform object backup or restore on a cluster that uses HDFS storage locations.

Impact of backups on database nodes

While a backup is taking place, the backup process can consume additional storage. The amount of space consumed depends on the size of your catalog and any objects that you drop during the backup. The backup process releases this storage when the backup is complete.

Best practices for creating backups

When creating backup configuration files:

Create separate configuration files to create full and object-level backups.
Use a unique snapshot name in each configuration file.
Use the same backup host directory location for both kinds of backups:
- Because the backups share disk space, they are compatible when performing a restore.
- Each cluster node must also use the same directory location on its designated backup host.
For best network performance, use one backup host per cluster node.
Use one directory on each backup node to store successive backups.
For future reference, append the major OpenText™ Analytics Database version number to the configuration file name (mybackup9x).

The selected objects of a backup can include one or more schemas or tables, or a combination of both. For example, you can include schema S1 and tables T1 and T2 in an object-level backup. Multiple backups can be combined into a single backup. A schema-level backup can be integrated with a database backup (and a table backup integrated with a schema-level backup, and so on).

Admin: Restoring backups

Mon, 01 Jan 0001 00:00:00 +0000

You can use the vbr restore task to restore your full database or selected objects from backups created by vbr. Typically you use the same configuration file for both operations. The minimal restore command is:

$ vbr --task restore --config-file config-file

You must log in using the database administrator's account (not root).

For full restores, the database must be DOWN. For object restores, the database must be UP.

Usually you restore to the cluster that you backed up, but you can also restore to an alternate cluster if the original one is no longer available.

Restoring must be done on the same architecture as the backup from which you are restoring. You cannot back up an Enterprise Mode database and restore it in Eon Mode or vice versa.

You can perform restore tasks on Permanent node types. You cannot restore data on Ephemeral, Execute, or Standby nodes. To restore or replicate to these nodes, you must first change the destination node type to PERMANENT. For more information, refer to Setting node type.

Restoring objects to a higher version

OpenText™ Analytics Database supports restoration to a database that is no more than one minor version higher than the current database version. For example, you can restore objects from a 12.0.x database to a 12.1.x database.

If restored objects require a UDx library that is not present in the later-version database, the database displays the following error:

ERROR 2858:  Could not find function definition

You can resolve this issue by installing compatible libraries in the target database.

Restoring HDFS storage locations

If your database cluster uses HDFS storage locations, you must do some additional configuration before you can restore. See Requirements for backing up and restoring HDFS storage locations.

HDFS storage locations support only full backup and restore. You cannot perform object backup or restore on a cluster that uses HDFS storage locations.

Admin: Copying the database to another cluster

Mon, 01 Jan 0001 00:00:00 +0000

Important

The vbr task copycluster combines two other vbr tasks— backup and restore—as a single operation, enabling you to back up an entire data from one Enterprise Mode database cluster and then restore it on another. This can facilitate routine operations, such as copying a database between development and production environments.

Caution

copycluster overwrites all existing data in the destination database. To preserve that data, back up the destination database before launching the copycluster task.

Restrictions

copycluster is invalid with Eon databases. It is also incompatible with HDFS storage locations; OpenText™ Analytics Database does not transfer data to a remote HDFS cluster as it does for a Linux cluster.

Prerequisites

copycluster requires that the target and source database clusters be identical in the following respects:

Database hotfix version—for example, 12.0.1-1

Number of nodes and node names, as shown in the system table NODES:

=> SELECT node_name FROM nodes;
  node_name
------------------
 v_vmart_node0001
 v_vmart_node0002
 v_vmart_node0003
(3 rows)

Database name

Database catalog, data, and temp directory paths as shown in the system table DISK_STORAGE:

=> SELECT node_name,storage_path,storage_usage FROM disk_storage;
    node_name     |                     storage_path                     | storage_usage
------------------+------------------------------------------------------+---------------
 v_vmart_node0001 | /home/dbadmin/VMart/v_vmart_node0001_catalog/Catalog | CATALOG
 v_vmart_node0001 | /home/dbadmin/VMart/v_vmart_node0001_data            | DATA,TEMP
 v_vmart_node0001 | /home/dbadmin/verticadb                              | DEPOT
 v_vmart_node0002 | /home/dbadmin/VMart/v_vmart_node0002_catalog/Catalog | CATALOG
...

Note

Directory paths for the catalog, data, and temp storage are the same on all nodes.

Database administrator accounts

The following requirements also apply:

The target cluster has adequate disk space for copycluster to complete.
The source cluster's database administrator must be able to log in to all target cluster nodes through SSH without a password.

Note
Passwordless access within the cluster is not the same as passwordless access between clusters. The SSH ID of the administrator account on the source cluster and the target cluster are likely not the same. You must configure each host in the target cluster to accept the SSH authentication of the source cluster.

Copycluster procedure

Create a configuration file for the copycluster operation. The OpenText™ Analytics Database installation includes a sample configuration file:
```
/opt/vertica/share/vbr/example_configs/copycluster.ini
```
For each node in the source database, create a [Mapping] entry that specifies the host name of each destination database node. Unlike other vbr tasks such as restore and backup, mappings for copycluster only require the destination host name. copycluster always stores backup data in the catalog and data directories of the destination database.

The following example configures vbr to copy the vmart database from its three-node v_vmart cluster to the test-host cluster:
```
[Misc]
snapshotName = CopyVmart
tempDir = /tmp/vbr

[Database]
dbName = vmart
dbUser = dbadmin
dbPassword = password
dbPromptForPassword = False

[Transmission]
encrypt = False
port_rsync = 50000

[Mapping]
; backupDir is not used for cluster copy
v_vmart_node0001= test-host01
v_vmart_node0002= test-host02
v_vmart_node0003= test-host03
```
Stop the target cluster.

As database administrator, invoke the vbr task copycluster from a source database node:

$ vbr -t copycluster -c copycluster.ini
Starting copy of database VMART.
Participating nodes: vmart_node0001, vmart_node0002, vmart_node0003, vmart_node0004.
Enter vertica password:
Snapshotting database.
Snapshot complete.
Determining what data to copy.
[==================================================] 100%
Approximate bytes to copy: 987394852 of 987394852 total.
Syncing data to destination cluster.
[==================================================] 100%
Reinitializing destination catalog.
Copycluster complete!

Important

If the copycluster task is interrupted, the destination cluster retains data files that already transferred. If you retry the operation, the database does not resend these files.

Admin: Replicating objects to another database cluster

Mon, 01 Jan 0001 00:00:00 +0000

The vbr task replicate supports replication of tables and schemas from one database cluster to another. You might consider replication for the following reasons:

Copy tables and schemas between test, staging, and production clusters.Replicate certain objects immediately after an important change, such as a large table data load, instead of waiting until the next scheduled backup.

In both cases, replicating objects is generally more efficient than exporting and importing them. The first replication of an object replicates the entire object. Subsequent replications copy only data that has changed since the last replication. OpenText™ Analytics Database replicates data as of the current epoch on the target database. Used with a cron job, you can replicate key objects to create a backup database.

Replicate versus copycluster

replicate only supports tables, schemas, and—in Eon Mode databases—namespaces. In situations where the target database is down, or you plan to replicate the entire database, OpenText recommends that you use the copycluster task to copy the database to another cluster. Thereafter, you can use replicate to update individual objects.

Replication procedure

To replicate objects to another database, perform these actions from the source database:

Verify replication requirements.
Identify the objects to replicate and target database in the vbr configuration file.
Replicate objects.

Verify replication requirements

The following requirements apply to the source and target databases and their respective clusters:

All nodes in both databases are UP, else DOWN nodes are handled as described below.
Versions of the two databases must be compatible. OpenText™ Analytics Database supports object replication to a target database up to one minor version higher than the current database version. For example, you can replicate objects from a 12.0.x database to a 12.1.x database.
The same Linux user is associated with the dbadmin account of both databases.
The source cluster database administrator can log on to all target nodes through SSH without a password.

Note
The SSH ID of the administrator account on the source cluster and the target cluster are likely not the same. You must configure each host in the target cluster to accept the SSH authentication of the source cluster.
Enterprise Mode: The following requirements apply:
- Both databases have the same number of nodes.
- Clusters of both databases have the same number of fault groups, where corresponding fault groups in each cluster have the same number of nodes.
Eon Mode: The following requirements apply:
- The primary subclusters of both databases have the same node subscriptions.
- Primary subclusters of the target database have as many or more nodes as primary subclusters of the source database.
- For databases with multiple namespaces, the target and source namespaces must satisfy the requirements described in Eon Mode database requirements.

Edit vbr configuration file

Tip

As a best practice, create a separate configuration file for each replication task.

Edit the vbr configuration file to use for the replicate task as follows:

In the [misc] section, set the objects parameter to the objects to be replicated:
```
; Identify the objects that you want to replicate
objects = schema.objectName    
```
Important
If your Eon Mode database has multiple namespaces, you must specify the namespace to which the objects belong. For vbr tasks, namespace names are prefixed with a period. For example, .n.s.t refers to table t in schema s in namespace n. See Eon Mode database requirements for more information.
In the [misc] section, set the snapshotName parameter to a unique snapshot identifier. Multiple replicate tasks can run concurrently with each other and with backup tasks, but only if their snapshot names are different.
```
snapshotName = name
```
In the [database] section, set the following parameters:
```
; parameters used to replicate objects between databases
dest_dbName =
dest_dbUser =
dest_dbPromptForPassword =
```
If you use a stored password, be sure to configure the dest_dbPassword parameter in your password configuration file.

In the [mapping] section, map source nodes to target hosts:

[Mapping]
v_source_node0001 = targethost01
v_source_node0002 = targethost02
v_source_node0003 = targethost03

Replicate objects

Run vbr with the replicate task:

vbr -t replicate -c configfile.ini

The replicate task can run concurrently with backup and other replicate tasks in either direction, provided all tasks have unique snapshot names. replicate cannot run concurrently with other vbr tasks.

Handling DOWN nodes

You can replicate objects if some nodes are down in either the source or target database, provided the nodes are visible on the network.

The effect of DOWN nodes on a replication task depends on whether they are present in the source or target database.

Location	Effect on replication
DOWN source nodes	The database can replicate objects from a source database containing DOWN nodes. If nodes in the source database are DOWN, set the corresponding nodes in the target database to DOWN as well.
DOWN target nodes	The database can replicate objects when the target database has DOWN nodes. If nodes in the target database are DOWN, exclude the corresponding source database nodes using the `--nodes` parameter on the `vbr` command line.

Monitoring object replication

You can monitor object replication in the following ways:

View vbr logs on the source database
Check database logs on the source and target databases
Query REMOTE_REPLICATION_STATUS on the source database

Admin: Including and excluding objects

Mon, 01 Jan 0001 00:00:00 +0000

You specify objects to include in backup, restore, and replicate operations with the vbr configuration and command-line parameters includeObjects and --include-objects, respectively. You can optionally modify the set of included objects with the vbr configuration and command line parameters excludeObjects and --exclude-objects, respectively. Both parameters support wildcard expressions to include and exclude groups of objects.

Important

If your Eon Mode database has multiple namespaces, you must specify the namespace to which the objects belong. For vbr tasks, namespace names are prefixed with a period. For example, .n.s.t refers to table t in schema s in namespace n. See Eon Mode database requirements for more information.

For example, you might back up all tables in the schema store, and then exclude from the backup the table store.orders and all tables in the same schema whose name includes the string account:

vbr --task=backup --config-file=db.ini --include-objects 'store.*' --exclude-objects 'store.orders,store.*account*'

Wildcard characters

Character	Description
?	Matches any single character. Case-insensitive.
	Matches 0 or more characters. Case-insensitive.
\	Escapes the next character. To include a literal ? or * in your table or schema name, use the \ character immediately before the escaped character. To escape the \ character itself, use a double \.
"	Escapes the . character. To include a literal . in your table or schema name, wrap the character in double quotation marks.

Matching schemas

Any string pattern without a period (.) character represents a schema. For example, the following includeObjects list can match any schema name that starts with the string customer, and any two-character schema name that starts with the letter s:

includeObjects = customer*,s?

When a vbr operation specifies a schema that is unqualified by table references, the operation includes all tables of that schema. In this case, you cannot exclude individual tables from the same schema. For example, the following vbr.ini entries are invalid:

; invalid:
includeObjects = VMart
excludeObjects = VMart.?table?

You can exclude tables from an included schema by identifying the schema with the pattern schemaname.*. In this case, the pattern explicitly specifies to include all tables in that schema with the wildcard *. In the following example, the include-objects parameter includes all tables in the VMart schema, and then excludes specific tables—specifically, the table VMart.sales and all VMart tables that include the string account:


--include-objects 'VMart.*'
--exclude-objects 'VMart.sales,VMart.*account*'

Matching tables

Any pattern that includes a period (.) represents a table. For example, in a configuration file, the following includeObjects list matches the table name sales.newclients, and any two-character table name in the same schema:

includeObjects = sales.newclients,sales.??

You can also match all schemas and tables in a database or backup by using the pattern *.*. For example, you can restore all tables and schemas in a backup using this command:

--include-objects '*.*'

Because a vbr parameter is evaluated on the command line, you must enclose the wildcards in single quote marks to prevent Linux from misinterpreting them.

Testing wildcard patterns

You can test the results of any pattern by using the --dry-run parameter with a backup or restore command. Commands that include --dry-run do not affect your database. Instead, vbr displays the result of the command without executing it. For more information on --dry-run, refer to the vbr reference.

Using wildcards with backups

You can identify objects to include in your object backup tasks using the includeObjects and excludeObjects parameters in your configuration file. A typical configuration file might include the following content:

[Misc]
snapshotName = dbobjects
restorePointLimit = 1
enableFreeSpaceCheck = True
includeObjects = VMart.*,online_sales.*
excludeObjects = *.*temp*

In this example, the backup would include all tables from the VMart and online_sales schemas, while excluding any table containing the string 'temp' in its name belonging to any schema.

After it evaluates included objects, vbr evaluates excluded objects and removes excluded objects from the included set. For example, if you included schema1.table1 and then excluded schema1.table1, that object would be excluded. If no other objects were included in the task, the task would fail. The same is true for wildcards. If an exclusion pattern removes all included objects, the task fails.

Using wildcards with restore

You can identify objects to include in your restore tasks using the --include-objects and --exclude-objects parameters.

Note

Take extra care when using wildcard patterns to restore database objects. Depending on your object restore mode settings, restored objects can overwrite existing objects. Test the impact of a wildcard restore with the --dry-run vbr parameter before performing the actual task.

As with backups, vbr evaluates excluded objects after it evaluates included objects and removes excluded objects from the included set. If no objects remain, the task fails.

A typical restore command might include this content. (Line wrapped in the documentation for readability, but this is one command.)

$ vbr -t restore -c verticaconfig --include-objects 'customers.*,sales??'
    --exclude-objects 'customers.199?,customers.200?'

This example includes the schema customers, minus any tables with names matching 199 and 200 plus one character, as well as all any schema matching 'sales' plus two characters.

Another typical restore command might include this content.

$ vbr -t restore -c replicateconfig --include-objects '*.transactions,flights.*'
    --exclude-objects 'flights.DTW*,flights.LAS*,flights.LAX*'

This example includes any table named transactions, regardless of schema, and any tables beginning with DTW, LAS, or LAX belonging to the schema flights. Although these three-letter airport codes are capitalized in the example, vbr is case-insensitive.

Admin: Managing backups

Mon, 01 Jan 0001 00:00:00 +0000

Important

vbr provides several tasks related to managing backups: listing them, checking their integrity, selectively deleting them, and more. In addition, vbr has parameters to allow you to restrict its use of system resources.

Admin: Troubleshooting backup and restore

Mon, 01 Jan 0001 00:00:00 +0000

These tips can help you avoid issues related to backup and restore with OpenText™ Analytics Database and to troubleshoot any problems that occur.

Check vbr log

The vbr log is separate from vertica.log. Its location is set by the vbr configuration parameter tempDir, by default /tmp/vbr.

If the log has no explanation for an error or unexpected results, try increasing the logging level with the vbr option --debug:

vbr -t backup -c config-file --debug debug-level

where debug-level is an integer between 0 (default) and 3 (verbose), inclusive. As you increase the logging level, the file size of the log increases. For example:

$ vbr -t backup -c full_backup.ini --debug 3

Note

Scrutinize reports do not include vbr logs.

Check status of backup nodes

Backups fail if you run out of disk space on the backup hosts or if vbr cannot reach them all. Check that you have sufficient space on each backup host and that you can reach each host via ssh.

Sometimes vbr leaves rsync processes running on the database or backup nodes. These processes can interfere with new ones. If you get an rsync error in the console, look for runaway processes and kill them.

Common errors

Object replication fails

If you do not exclude the DOWN node, replication fails with the following error:

Error connecting to a destination database node on the host <hostname> : <error>  ...

Confirm that you excluded all DOWN nodes from the object replication operation.

Error restoring an archive

You might see an error like the following when restoring an archive:

$ vbr --task restore --archive prd_db_20190131_183111 --config-file /home/dbadmin/backup.ini
IOError: [Errno 2] No such file or directory: '/tmp/vbr/vbr_20190131_183111_s0rpYR/prd_db.info'

The problem is that the archive name is not in the correct format. Specify only the date/timestamp suffix of the directory name that identifies the archive to restore, as described in Restoring an Archive. For example:

$ vbr --task restore --archive 20190131_183111 --config-file /home/dbadmin/backup.ini

Backup or restore fails when using an HDFS storage location

When performing a backup of a cluster that includes HDFS storage locations, you might see an error like the following:

ERROR 5127:  Unable to create snapshot No such file /usr/bin/hadoop:
check the HadoopHome configuration parameter

This error is caused by the backup script not being able to back up the HDFS storage locations. You must configure OpenText™ Analytics Database and Hadoop to enable the backup script to back up these locations. See Requirements for backing up and restoring HDFS storage locations.

Object-level backup and restore are not supported with HDFS storage locations. You must use full backup and restore.

Could not connect to endpoint URL

(Eon Mode) When performing a cross-endpoint operation, you can see a connection error if you failed to specify the endpoint URL for your communal storage (VBR_COMMUNAL_STORAGE_ENDPOINT_URL). When the endpoint is missing but you specify credentials for communal storage, vbr tries to use those credentials to access AWS. This access fails, because those credentials are for your on-premises storage, not AWS. When performing cross-endpoint operations, check that all environment variables described in Cross-Endpoint Backups in Eon Mode are set correctly.

Admin: vbr reference

Mon, 01 Jan 0001 00:00:00 +0000

vbr can back up and restore the full database, or specific schemas and tables. It also supports a number of other backup-related tasks—for example, list the history of all backups.

vbr is located in the OpenText™ Analytics Database binary directory—typically, /opt/vertica/bin/vbr.

Syntax

vbr { --help | -h }
  | { --task | -t } task  { --config-file | -c } configfile [ option[...] ]

Global options

The following options apply to all vbr tasks. For additional options, see Task-Specific Options.

Option	Description
`--help \| -h`	Display a brief `vbr` usage guide.
`{--task \| -t}` `task`	The `vbr` task to execute, one of the following: backup: create a full or object-level backup collect-garbage: rebuild the backup manifest and delete any unreferenced objects in the backup location copycluster: copy the database to another cluster (Enterprise Mode only, invalid for HDFS) full-check: verify all objects in the backup manifest and report missing or unreferenced objects init: prepare a new backup location listbackup: show available backups quick-check: confirm that all backed-up objects are in the backup manifest and report discrepancies between objects in the backup location and objects listed in the backup manifest quick-repair: build a replacement backup manifest based on storage locations and objects remove: remove specified restore points replicate: copy objects from one cluster to another restore: restore a full or object-level backup Note In general, tasks cannot run concurrently, with one exception: multiple `replicate` tasks can run concurrently with each other, and with `backup`.
`{--config-file \| -c}` `path`	File path of the configuration file to use for the given task.
`--debug` `level`	Level of debug messaging to the `vbr` log, an integer from 0 to 3 inclusive, where 0 (default) turns off debug messaging, and 3 is the most verbose level of messaging.
`--nodes` `nodeslist`	(Enterprise Mode only) Comma-delimited list of nodes on which to perform a `vbr` task. Listed nodes must match names in the Mapping section of the configuration file. Use this option to exclude DOWN nodes from a task, so `vbr` does not return with an error. Caution If you use `--nodes` with a `backup` task, be sure that the nodes list includes all UP nodes; omitting any UP node can cause data loss in that backup.
`--showconfig`	Displays the configuration values used to perform a specific task, displayed in raw JSON format before `vbr` starts task execution: `vbr -t` `task``-c``configfile` `--showconfig` `--showconfig` can also show settings for a given configuration file: `vbr -c` `configfile` `--showconfig`

Task-specific options

Some vbr tasks support additional options, described in the sections that follow.

The following vbr tasks have no task-specific options:

copycluster
quick-check
quick-repair

Backup

Create a full database or object-level backup, depending on configuration file settings.

Option	Description
`--dry-run`	Perform a test run to evaluate impact of the backup operation—for example, its size and potential overhead.

Collect-garbage

Rebuild the backup manifest and delete any unreferenced objects in the backup location.

Option	Description
`--report-file`	Output results to a delimited JSON file.

Full-check

Produce a full backup integrity check that verifies all objects in the backup manifest against file system metadata, and then outputs missing and unreferenced objects.

Option	Description
`--report-file`	Output results to a delimited JSON file.

Init

Create a backup directory or prepare an existing one for use, and create backup manifests. This task must precede the first vbr backup operation.

Option	Description
`--cloud-force-init`	Qualifies the `--task init` command to force the `init` task to succeed on S3 or GS storage targets when an identity/lock file mismatch occurs.
`--report-file`	Output results to a delimited JSON file.

Listbackup

Displays backups associated with the specified configuration file. Use this task to get archive (restore point) identifiers for restore and remove tasks.

Option	Description
`--list-all`	List all backups stored on the hosts and paths in the configuration file.
`--list-output-file` `filename`	Redirect output to the specified file.
`--json`	Use JSON delimited format.

Remove

Remove the backup restore points specified by the --archive option.

Option Description

Option	Description
`--archive`	Restore points to remove, one of the following: `timestamp`: A single restore point to remove. `timestamp``:``timestamp`: A range of contiguous restore points to remove. `all`: Remove all restore points. You obtain timestamp identifiers for the target restore points with the `listbackup` task. For details, see vbr listbackup.

--archive

Restore points to remove, one of the following:

timestamp: A single restore point to remove.
timestamp:timestamp: A range of contiguous restore points to remove.
all: Remove all restore points.

You obtain timestamp identifiers for the target restore points with the listbackup task. For details, see vbr listbackup.

Replicate

Copy objects from one cluster to an alternate cluster. This task can run concurrently with backup and other replicate tasks.

Option Description

--archive Timestamp of the backup restore point to replicate, obtained from the listbackup task.

--dry-run Perform a test run to evaluate impact of the replicate operation—for example, its size and potential overhead.

Option	Description
`--archive`	Timestamp of the backup restore point to replicate, obtained from the `listbackup` task.
`--dry-run`	Perform a test run to evaluate impact of the replicate operation—for example, its size and potential overhead.
`--target-namespace`	Eon Mode only, the namespace in the target database to which objects are 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.

--target-namespace

Eon Mode only, the namespace in the target database to which objects are 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.

Restore

Restore a full or object-level database backup.

Option	Description
`--archive`	Timestamp of the backup to restore, obtained from the `listbackup` task. If omitted, `vbr` restores the latest backup of the specified configuration.
`--restore-objects`	Comma-delimited list of objects—tables and schemas—to restore from a given backup.
`--include-objects`	Comma-delimited list of database objects or patterns of objects to include from a full or object-level backup.
`--exclude-objects`	Comma-delimited list of database objects or patterns of objects to exclude from the set specified by `--include-objects`. This option can only be used together with `--include-objects`.
`--dry-run`	Perform a test run to evaluate impact of the restore operation—for example, its size and potential overhead.
`--target-namespace`	Eon Mode only, the namespace in the target database to which objects are restored. `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.

Note

The --restore-objects option and the --include-objects/exclude-objects options are mutually exclusive. You can use --include-objects to specify a set of objects and combine it with --exclude-objects to remove objects from the set.

Interrupting vbr

To cancel a backup, use Ctrl+C or send a SIGINT to the vbr Python process. vbr stops the backup process after it completes copying the data. Canceling a vbr backup with Ctrl+C closes the session immediately.

The files generated by an interrupted backup process remain in the target backup location directory. The next backup process picks up where the interrupted process left off.

Backup operations are atomic, so interrupting a backup operation does not affect the previous backup. The latest backup replaces the previous backup only after all other backup steps are complete.

Caution

restore or copycluster operations overwrite the database catalog directory. Interrupting either of these processes leaves the database unusable until you restart the process and allow it to finish.

Admin: vbr configuration file reference

Mon, 01 Jan 0001 00:00:00 +0000

vbr configuration files divide backup settings into sections, under section-specific headings such as [Database] and [CloudStorage], which contain database access and cloud storage location settings, respectively. Sections can appear in any order and can be repeated—for example, multiple [Database] sections.

Important

Section headings are case-sensitive.