Restoring Object-Level Backups

To restore an object-level backup to the database from which it was taken, the database must be UP. The vbr configuration file you use for the restore task specifies the backup to restore.

You can specify how Vertica reacts to duplicate objects by configuring the objectRestoreMode setting in your vbr configuration file.

Restoring Objects to a Changed Cluster

Unlike restoring from a full database backup, vbr supports restoring object-level backups after adding nodes to the cluster. Any nodes that were not in the cluster when you created the object-level backup do not participate in the restore. You can rebalance your cluster after the restore to distribute data among the new nodes.

You cannot restore an object-level backup after removing nodes, altering node names, or changing IP addresses. Trying to restore an object-level backup after such changes causes vbr to fail and display this message:

Preparing... 
Topology changed after backup; cannot restore. 
restore failed!

Projection Epoch After Restore

All object-level backup and restore events are treated as DDL events. If a table does not participate in an object-level backup, possibly because a node being down, restoring the backup affects the projection in the following ways:

Its epoch is reset to 0.
It must recover any data that it does not have by comparing epochs and other recovery procedures.

Catalog Locks During Backup Restore

As with other databases, Vertica transactions follow strict locking protocols to maintain data integrity.

When restoring an object-level backup into a cluster that is UP vbr begins by copying data and managing storage containers. If necessary, vbr splits the containers.This process does not require any database locks.

After completing data copying tasks, vbr first requires a table object lock (O-lock) and then a global catalog lock (GCLX).

Sometimes, other database operations, such as DML statements, are in progress when the process attempts to get an O-lock on the table. In such cases, vbr is blocked from progress until the DML statement completes and releases the lock. After securing an O-lock first, and then a GCLX lock, vbr blocks other operations that require a lock on the same table.

To guarantee catalog consistency, processes can hold a GCLX for a minimal duration. When the restore locks are in effect, any concurrent table modifications are blocked until both locks are released. Database system operations, such as the Tuple Mover (TM) transferring data from memory to disk, are canceled to permit the object-level restore to complete.

Catalog Restore Events

Each object-level backup includes a section of the database catalog, called a snippet. A snippet contains the selected objects, their dependent objects, and principal objects. A catalog snippet is similar in structure to the database catalog but consists of a subset representing the object information. Objects being restored can be read from the catalog snippet and used to update both global and local catalogs.

Each object from a restored backup is updated in the catalog. If the object no longer exists, vbr drops the object from the catalog. Any dependent objects that are not in the backup are also dropped from the catalog.

The vbr utility uses existing dependency verification methods to check the catalog and adds a restore event to the catalog for each restored table. That event also includes the epoch at which the event occurred. If a node misses the restore table event, it recovers projections anchored on the given table.

Catalog Size Limitations

Object level restores can fail if your catalog size is greater than five percent of the total memory available in the node performing the restore. In this situation, Open Text Corporation recommends restoring individual objects from the backup. For more information, refer to Restoring Individual Objects from a Full or Object-Level Backup.