Incremental backup and recovery
As the size of databases, and particularly warehouses, continues to expand into the terabyte and petabyte range, the time and hardware resources required to back up and recover these databases is also growing substantially.
A full backup is a backup image, either database or table space, that contains all pages in the database or table space set being backed up. Each full database or table space backup image also contains all of the initial database metadata (such as database configuration, table space definitions, database history, and so on).
Full database and table space backups are not always the best approach when dealing with large databases, because the storage requirements for multiple copies of such databases are enormous.
- When a small percentage of the data in a warehouse changes, it should not be necessary to back up the entire database.
- Appending table spaces to existing databases and then taking only table space backups is risky, because there is no guarantee that nothing outside of the backed up table spaces has changed between table space backups.
To address these issues, Db2® provides incremental backup and recovery.
- If you take an incremental backup of a table space that contains pages that have been updated since the previous backup was taken, all long field or large object data will be copied into the backup image. Normal data is backed up only if it has changed. That is, if the user does not want all large object data that do not change to be backed up in the incremental backup image, they should put all large object data that do not change and normal data that changes in separate table spaces, respectively. This way, the table space that contains all large object data that do not change will not be backed up in the incremental backup image.
- Data redistribution might create table spaces for all new database partitions if the ADD DBPARTITIONNUMS parameter on the REDISTRIBUTE DATABASE PARTITION GROUP command is specified. In this case, take a full backup of all newly created table spaces on all database partitions before taking next incremental backup.
- The incremental backup does not guarantee improved performance compared to the full backup. For example, if there are many pages have been updated since the previous backup was taken and these pages reside in each table space of the database, the incremental backup performance will be close to the full backup performance.
- Incremental. An incremental backup image is a copy of all database data that has changed since the most recent, successful, full backup operation. This is also known as a cumulative backup image, because a series of incremental backups taken over time will each have the contents of the previous incremental backup image. The predecessor of an incremental backup image is always the most recent successful full backup of the same object.
- Delta. A delta, or incremental delta, backup image is a copy of all database data that has changed since the last successful backup (full, incremental, or delta) of the table space in question. This is also known as a differential, or noncumulative, backup image. The predecessor of a delta backup image is the most recent successful backup containing a copy of each of the table spaces in the delta backup image.
The key difference between incremental and delta backup images is their behavior when successive backups are taken of an object that is continually changing over time. Each successive incremental image contains the entire contents of the previous incremental image, plus any data that has changed, or is new, since the previous full backup was produced. Delta backup images contain only the pages that have changed since the previous image of any type was produced.
Combinations of database and table space incremental backups are permitted, in both online and offline modes of operation. Be careful when planning your backup strategy, because combining database and table space incremental backups implies that the predecessor of a database backup (or a table space backup of multiple table spaces) is not necessarily a single image, but could be a unique set of previous database and table space backups taken at different times.
To restore the database or the table space to a consistent state, the recovery process must begin with a consistent image of the entire object (database or table space) to be restored, and must then apply each of the appropriate incremental backup images in the order described in the following list.
- NO. Incremental backup is not permitted with this configuration. Database page updates are not tracked or recorded in any way. This is the default value.
- YES. Incremental backup is permitted with this configuration. When update tracking is enabled, the change becomes effective at the first successful connection to the database. Before an incremental backup can be taken on a particular table space, a full backup of that table space is necessary.
For SMS and DMS table spaces, the granularity of this tracking is at the table space level. In table space level tracking, a flag for each table space indicates whether or not there are pages in that table space that need to be backed up. If no pages in a table space need to be backed up, the backup operation can skip that table space altogether.
Although minimal, the tracking of updates to the database can have an impact on the runtime performance of transactions that update or insert data.