Types of Backups

vbr supports the following kinds of backups: 

The vbr configuration file includes the snapshotName parameter. Use different snapshot names for different types of backups, including different combinations of objects in object-level backups. Backups with the same snapshot name form a time sequence limited by restorePointLimit, so if you give all your backups the same snapshot name, they will eventually interfere with each other.

Full Backups

A full backup is a complete copy of the database catalog, its schemas, tables, and other objects. This type of backup provides a consistent image of the database at the time the backup occurred. You can use a full backup for disaster recovery to restore a damaged or incomplete database. You can also restore individual objects from a full backup.

When a full backup already exists, vbr backs up new or changed data since the last full backup occurred, rather than making another complete copy. You can specify the number of historical backups to keep.

Archives contain a collection of same-name backups. Each archive can have a different retention policy. For example, suppose that TBak is the name of an object-level backup of table T, and you create a daily backup each week. These seven backups become part of the TBak archive. Keeping a backup archive lets you revert back to any one of the saved backups.

Object-Level Backups

An object-level backup consists of one or more schemas or tables or a group of such objects. The conglomerate parts of the object-level backup do not contain the entire database. When an object-level backup exists, you can restore all of its contents or individual objects. Object-level backups are supported for Enterprise Mode databases only.

Vertica does not support object level backups on Hadoop Distributed File System (HDFS) storage.

Object-level backups contain the following object types: 

Selected objects Objects you choose to be part of an object-level backup. For example, if you specify tables T1 and T2 to include in an object-level backup, they are the selected objects.
Dependent objects

Objects that must be included as part of an object-level backup, due to dependencies. Suppose you want to create an object-level backup that includes a table with a foreign key. To do so, table constraints require that you include the primary key table, and vbr enforces this requirement. Projections anchored on a table in the selected objects are also dependent objects.

Principal objects

The objects on which both selected and dependent objects depend are called principal objects. For example, each table and projection has an owner, and each is a principal object.

Hard-Link Local Backups

You can make a faster local backup, either for the full database or for specific objects, directly on the database nodes. Typically you use this kind of backup temporarily before performing a disruptive operation. Do not rely on this kind of backup for long-term use; it cannot protect you from node failures because data and backups are on the same nodes.

A checkpoint backup is called a hard-link local backup. It consists of a complete copy of the database catalog, and a set of hard file links to corresponding data files. You must save a hard-link local backup on the file system used by the catalog and database files.

Hard-link local backups are supported in Enterprise Mode only.