15.11 - About Backup Types - Data Stream Architecture

Teradata Data Stream Architecture (DSA) User Guide

Data Stream Architecture
December 2016
User Guide

The Teradata incremental backup and restore feature is available when running the combination of Teradata DSA 14.11 (or later) and Teradata Database 14.10 (or later). Teradata implements incremental database backup using the Changed Block Backup (CBB) feature. With CBB, a Teradata Database System will only back up data blocks that have changed since a prior backup operation. This can greatly reduce the time and storage required to perform backups, at the cost of an increase in overall restore time. Overall restore time is increased because DSA has to read multiple datasets from disk or tape media and construct the complete dataset to restore. Incremental backup is applicable to both standard backup and online archive.

Incremental backup is appropriate for:
  • Databases and tables that have a very low change rate compared to table size
  • Primary Partition Index (PPI) tables for which changes are limited to one or few partitions

The incremental backup feature allows three types of backups: full, delta, and cumulative.

Backup Types

A full backup archives all data from the specified objects. This backup takes the longest time to complete, and uses the most backup storage space. However, a full backup has the shortest restore time, since all data required to restore the objects will be contained within a single backup image.
A full backup must be initially performed prior to any other type of backup. The full backup will be used as a baseline for further incremental steps.
A delta backup archives only the data which has changed since the last backup operation. This backup will complete in the shortest time and use the least storage space. However, a delta backup will increase the time to restore the database, as it potentially adds many backup images that must be processed before a set of objects can be fully restored.
A cumulative backup archives the data which has changed since the last full backup was run. This backup type consolidates changes from multiple delta backups or cumulative backups before a full backup is run. A cumulative backup has a shorter database restore time than a series of delta or cumulative backups, and it takes less time and space than a full backup.

Guidelines for Incremental Backups

If any save set is removed from the DSC repository, any subsequent run dependent on the removed save set is invalid. A save set would be removed, for example, if it was expired on the Backup Solution prior to the sync_save_sets command being run.

Regardless of the type of incremental backup performed, the dictionary information for all objects is fully backed up. This ensures that all non-data objects and object definitions are fully recovered to the point in time in the event of a restore from any increment.

In the event of a restore or analyze_validate, you select the backup image corresponding to the point in time to which the objects should be restored. This can be a full, delta, or cumulative backup image. For a given restore scenario (point in time), the following images are processed, relative to the selected backup image:
  • The most recent full backup
  • The most recent cumulative backup, if any. Only if newer than the full backup.
  • Any delta backups after the most recent full or cumulative, and the selected restore point in time
In the event of an analyze_read, only the selected save set is analyzed.
Running a cumulative or delta incremental backup of a DBC ALL backup job does not include the DBC system tables. The DBC database is used when you need to restore the whole system after a system initialization (sysinit). Therefore, run a separate FULL backup of the DBC database for every incremental backup job cycle run.

Allowing Incremental Jobs Based on Full or Cumulative Backup Jobs Completed with Errors

See the Usage Notes in config_systems.