Creating Object-Level Backups

The database administrator can create object-level backups consisting of one or more schemas and tables. Object-level backups are especially useful for multi-tenanted database sites. For example, an international airport could use a multi-tenanted database to represent different airlines in its schemas. Then, tables could maintain various types of information for the airline, including ARRIVALS, DEPARTURES, and PASSENGER information. With such an organization, creating object-level backups of the specific schemas would let you restore by airline tenant, or any other important data segment.

The following configuration file parameters are specific to object-level backups:

Objects
objectRestoreMode (used in restore operations only)

For more information about creating configuration files for full or object-level backups, see Configuring Required VBR Parameters.

Note: Apache Kafka uses internal configuration settings to maintain the integrity of your data. When backing up your Kafka data, Open Text Corporation recommends that you perform a full database backup, rather than an object- level backup.

Preparing Your Backup Directory

Before you can create a backup, you must prepare your backup directory with the vbr -init task.

Invoking vbr Backup

After creating the configuration file specifying which objects to backup, you can create an object-level backup. The following example shows how you can use the objectbak.ini command in a configuration file:

[dbadmin@v_vmart_node0001 ~]$ vbr --task backup --config-file objectbak.ini
Preparing...
Found Database port:  5433
Copying... 
[==================================================] 100%
All child processes terminated successfully.
Committing changes on all backup sites...
backup done!
[dbadmin@v_vmart_node0001 ~]$

Backup Locations and Naming

You can use one top-level backup directory to store both full and object-level backups.

Note: Open Text Corporation 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 incremental backups.

To see existing full and object-level backups, see Viewing Backups in the See Also section below.

Best Practices for Object-Level Backups

To create one or more object-level backups, create a configuration file specifying the backup location, the object-level backup name, and a list of objects to include (one or more schemas and tables). When creating configuration backup files:

Create one configuration file for each object-level backup
Create a different configuration file to create a full database backup
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 Vertica version number to the configuration file name (mybackup7x)

Using the same backup host directory location for full and object-level backups results in the backups sharing disk space. Shared disk space makes backups compatible when performing a restore. Each cluster node must also use the same directory location on its designated backup host.

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).

Naming Conventions

Give each object-level backup configuration file a distinct and descriptive name. For instance, at an airport terminal, schema-based backup configuration files use a naming convention with an airline prefix, followed by further description, such as:

AIR1_daily_arrivals_backup

AIR2_hourly_arrivals_backup

AIR2_hourly_departures_backup

AIR3_daily_departures_backup

When database and object-based backups exist, you can recover the backup of your choice.

Caution: Do not change object names in an object-level configuration file if a backup already exists. Doing so overwrites the original configuration file, and you cannot restore it from the earlier backup. Instead, create a different configuration file.

Determining Backup Frequency

Open Text Corporation recommends, as a best practice, that you take frequent backups if database contents diverge in significant ways.

Always take backups after any event that significantly modifies the database, such as performing a rebalance. Mixing many backups with significant differences can weaken data K-safety. For example, taking backups both before and after a rebalance is not a recommended practice in cases where the backups are all part of one archive.

Understanding Object-Level Backup Contents

Object-level backups comprise only the elements necessary to restore the schema or table, including the selected, dependent, and principal objects. An object-level backup includes the following contents:

Storage: Data files belonging to any specified objects
Metadata: Including the cluster topology, timestamp, epoch, AHM, and so on
Catalog snippet: Persistant catalog objects serialized into the principal and dependent objects

Some of the elements that comprise AIR2, for instance, include its parent schema, tables, named sequences, primary key and foreign key constraints, and so on. To create such a backup, vbr script saves the objects directly associated with the table. It also saves any dependencies, such as foreign key (FK) tables, and creates an object map from which to restore the backup.

Note: Because the data in local temp tables persists only within a session, local temporary tables are excluded when you create an object-level schema. For global temporary tables, vbr stores the table's definition.

Making Changes After an Object-Level Backup

Be aware how changes made after an object-level backup affect subsequent backups. Suppose you create an object-level backup and later drop schemas and tables from the database. In this case, the objects you dropped are also be dropped from subsequent backups. If you do not save an archive of the object backup, such objects could be lost permanently.

Changing a table name after creating a table backup does not persist after restoring the backup. Suppose that, after creating a backup, you drop a user who owns any selected or dependent objects in that backup. In this case, restoring the backup re-creates the object and assigns ownership to the user performing the restore. If the owner of a restored object still exists, that user retains ownership of the restored object.

To restore a dropped table from a backup:

Rename the newly created table from t1 to t2.
Restore the backup containing t1.
Restore t1. Tables t1 and t2 now coexist.

For information on how Vertica handles object overwrites, refer to "Specifying Object Restore Mode" in Creating vbr Configuration Files.

K-safety may increase after an object backup. Restoration of a backup fails if both of the following conditions occur:

An increase in K-safety occurs.
Any table in the backup has insufficient projections.

Changing Principal and Dependent Objects

If you create a backup and then drop a principal object, restoring the backup restores that principal object. If the owner of the restored object has also been dropped, Vertica assigns the restored object to the current dbadmin.

You can specify how Vertica handles object overwrites in the vbr configuration file. For more information, refer to "Specifying Object Restore Mode" in Creating vbr Configuration Files.

Identity and auto-increment sequences are dependent objects because they cannot exist without their tables. An object-level backup includes such objects, along with the tables on which they depend.

Named sequences are not dependent objects because they exist autonomously. A named sequence remains after you drop the table in which the sequence is used. In this case, the named sequence is a principal object. Thus, you must back up the named sequence with the table. Then, you regenerate it, if it does not already exist when you restore the table. If the sequence does exist, vbr uses it, unmodified. Sequence values could repeat, if you restore the full database and then restore a table backup to a newer epoch.

Considering Constraint References

You must backup all database objects that are related through constraints. For example, suppose you have a schema with tables whose constraints reference only tables in the same schema can be backed up. However, a schema containing a table with an FK/PK constraint on a table in another schema cannot. To back up the second table, you must include the other schema in the list of selected objects.

Configuration Files for Object-Level Backups

The vbr utility automatically associates configurations with different backup names but uses the same backup location.

Always create a cluster-wide configuration file and one or more object-level configuration files pointing to the same backup location. Storage between backups is shared, preventing multiple copies of the same data. For object-level backups, using the same backup location causes vbr to encounter fewer OID conflict prevention techniques. Avoiding OID conflict prevention results in fewer problems when restoring the backup.

By using cluster and object configuration files with the same backup location, the utility includes additional provisions to ensure that the object-level backups can be used following a full cluster restore. One approach to restoring a full cluster is to use a full database backup to bootstrap the cluster. After the cluster is operational again, you can restore the most recent object-level backups for schemas and tables.

Attempting to restore a full database using an object-level configuration file fails, resulting in this error:

Note:
VMart=> /tmp/vbr --config-file=Table2.ini -t restore
Preparing...
Invalid metadata file. Cannot restore.
restore failed!

Backup Epochs

Each backup includes the epoch to which its contents can be restored. When vbr restores data, Vertica updates to the current epoch.

The vbr utility attempts to create an object-level backup five times before an error occurs and the backup fails.