Product Documentation

Appearance

Backup Strategies ​

This section presents some examples that highlight how backups can be scheduled and combined to create an effective strategy.

Cumulative and incremental backups have some fundamental differences. A cumulative backup contains and subsumes changes that were captured by previous incremental backups. This means that a restore operation does not need the incremental backups when the database is restored to its state after a cumulative backup. The restore can skip the incremental backups and only has to "play back" the latest full backup and cumulative backup.

Cumulative and full backups both reset the "horizon" (or starting point) for subsequent backup operations. An incremental backup that follows a cumulative or full backup only picks up changes made since that backup. An incremental backup does not subsume any changes from any previous backups and does not reset the horizon for incremental restore operations. When restoring the database to its state after one or more incremental backups, restore operations cannot skip over those backups. They must be "played back" in order.

Important: A side-effect of these differences in backup types is that you cannot restore a database from a cumulative backup after you have already restored that database from an incremental backup. If you plan to restore a database periodically, as part of a routine schedule, you should restore it from the last cumulative or full backup. For example, if you plan to do proactive daily restores of a database, take daily cumulative backups of that database. Restoring from an incremental backup is recommended only in the event of a catastrophic failure, or if your strategy involves full and incremental backups only (no cumulative backups).

Some examples of restore paths follow in this section.

Restore Paths ​

Assume that a database has the following backups:

  1. A full backup taken on Monday (F1)
  2. An incremental backup taken on Tuesday (I2)
  3. An incremental backup taken on Wednesday (I3)
  4. A cumulative backup taken on Thursday (C4)

These backups are all valid "snapshots" of the database at a point in time. Each snapshot is a valid "restore point," but note the restore behavior when incremental and cumulative backups occur in a sequence.

  • A restore to F1 replays F1.
  • A restore to I2 replays F1 and I2. A subsequent attempt to restore to C4 will fail.
  • A restore to I3 replays F1, I2, and I3. A subsequent attempt to restore to C4 will fail.
  • A restore to C4 replays F1 and C4 only.

In the following example, the restore path has multiple steps because a failure occurs after a full backup and a series of cumulative backups. Any writes that occurred between transactions 5000 and 5010 would be lost, but the database could be fully recovered to the latest backup point, using the original full backup and the last four cumulative backups. All of the cumulative backups need to be applied as part of the restore sequence because they contain discrete sets of changes (assuming that continuous changes were made during that time frame). Note that this is a single restore operation from the user's point of view. You do not have to run multiple ybrestore commands to pick up each backup in the restore path.

Because only full and cumulative backups are used in this case, the database can be restored from any one of the cumulative backups without compromising subsequent backups in the chain. For example, you could restore to the backup at transaction 1500, then later restore to the backup at transaction 5000 if you needed to do that.

The following diagram shows a similar restore path when a failure occurs after a full backup and two incremental backups. Any writes that occurred between transactions 1500 and 2000 would be lost, but the database could be fully recovered to the latest backup point, using the original full backup and two subsequent incremental backups. Again, from the user's point of view, this is a single restore operation.

In the third example, a database is being incrementally restored every day. This works fine until a cumulative backup is taken after restores from incremental backups have already occurred. These restores break the restore path for the cumulative backup.

The solution in this case is one of the following:

  • Take only full and cumulative backups; do not use incremental backups.
  • Proactively restore only from full or cumulative backups. Restore from an incremental backup only as an emergency measure.

Choosing a Backup Strategy ​

In choosing your backup schedule and strategy, keep the following factors in mind:

  • Backups take place online so you do not need to schedule backups for periods when users are offline; however, backups require system resources that may detract from the resources available to other workloads.
  • How much and how often does the data in your databases actually change?
  • How much data can you afford to lose if an unexpected system failure occurs? (Or how long will it take to reload the lost data?)
  • Incremental backups take less time and resources to run than cumulative backups.
  • A mixture of incremental and cumulative backups may not serve your purpose for periodic restores. As noted earlier, having restored a database from an incremental backup, you will not be able to restore it from a subsequent cumulative backup.
  • You can delete a series of prior incremental backups once you have taken a cumulative backup. (Or you can just move the incrementals to another system for audit purposes.)
  • A series of cumulative backups may result in a waste of storage space, depending on the extent of the changes that they pick up.

Parent topic:Overview