Traditional Database Backup Techniques

All production Oracle databases require data protection. Oracle provides RMAN as its preferred backup solution. Most enterprises have adopted one or more of the database backup strategies described in this section:

• Weekly Full and Daily Incremental Backups

• Incremental Backups and RECOVER COPY

• Full Backups to a Third-Party Deduplicating Appliance

• Third-Party Storage Snapshots

Weekly Full and Daily Incremental Backups

One popular approach, shown in Figure 1, is to use RMAN to take a weekly full backup, and then daily incremental backups. To improve incremental backup performance, Oracle recommends enabling block change tracking. These backups occur when activity on the database is lowest.

Figure 1: Full and Incremental Backups to Tape

Description of the illustration amagd_vm_021.png

An advantage of this technique is that backup windows, which affect the production server, are relatively brief on the days when incremental backups occur. A disadvantage is that when the database is continuously active, as when serving multiple global time zones, no easily accommodating backup window is available.

One solution is to set up Oracle Data Guard, and then back up the standby database, thereby removing the backup load from the production server. However, protecting all databases with Oracle Data Guard is often impractical.

Incremental Backups and RECOVER COPY

The RMAN technique shown in Figure 2 makes daily incremental backups, and then uses the RECOVER COPY command to merge the incremental changes into the full database copy. In this way, the database copy on disk is “rolled forward” every day.

Figure 2: RECOVER COPY on Disk, and Backup to Tape

Description of the illustration amagd_vm_022.png

This technique has the following advantages:

• Only one initial full backup is required, which reduces the total weekly backup window time.

• An RMAN SWITCH command can point the control file to the database copy, which turns the copy into an actual database file, and thus eliminates the RESTORE step.

Some disadvantages are as follows:

• You must have sufficient disk space to keep a copy of the whole database on disk, and the archived redo log files required to recover it.

• Only one physical copy of the database exists. You select the point in time at which to keep the copy, so you can recover to subsequent points in time. For example, to restore to any point in time within the past week, your physical copy must be older than SYSDATE-7. The disadvantages are:

  • You cannot recover to a time earlier than the time at which you maintain the database copy.

  • The closer your recovery point in time is to the current time, the more incremental backups you must restore and apply to the copy. This technique adds time to the overall recovery time objective.

• The database copy cannot be compressed or encrypted.

Full Backups to a Third-Party Deduplicating Appliance

As an alternative to RMAN incremental backups and tape drives, some customers use third-party deduplicating appliances to process backup streams. Figure 3 depicts three databases writing to a centralized third-party appliance.

Figure 3: Third-Party Deduplicating Appliance

Description of the illustration amagd_vm_023.png

This technique has the following advantages:

• A central backup location serves all databases in the environment.

• The third-party software searches for patterns at the byte and sub-byte level to eliminate redundant data from backup to backup. For example, if a full database backup is almost identical to the backup taken a week before, then the software can attempt to prune the redundant bits from the incoming backup stream.

• To reduce network load, one optional technique utilizes source-side deduplication so that backup streams are deduplicated on the database host instead of the third-party appliance. Typically, this technique relies on an RMAN SBT plug-in.

Some disadvantages are as follows:

• These third-party appliances do not recognize or validate Oracle AI Database blocks. From the perspective of the appliance, a database backup is the same as a file system backup: a stream of bytes.

• Deduplication is only effective for full database backups that have a high degree of redundancy. Strategies that use incremental backups often do not achieve good deduplication ratios.

• The third-party appliance dictates which Oracle AI Database features to use rather than the other way around. Often, adapting to the requirements of the appliance means rewriting existing backup scripts.

Third-Party Storage Snapshots

A third-party storage snapshot is a set of pointers to storage blocks (not Oracle blocks) that existed when the snapshot was created. The virtual copies reside on the same storage array as the original data. Figure 4 depicts a copy-on-write snapshot, which is a type of third-party snapshot. After a snapshot is taken, when the first change to a storage block occurs, the array copies the before-image block to a new location on disk (C) and writes the new block (C') to the original location.

Figure 4: Third-Party Copy-on-Write Snapshot

Description of the illustration amagd_vm_024.png

This technique has the following advantages:

• An initial copy of the database is not necessary because snapshots are not stored as physical copies of blocks. Thus, less storage is consumed than in RMAN strategies.

• Snapshots can be extremely fast. You put the database in backup mode (unless storage does not meet the requirements for snapshot storage optimization), and then take the snapshot. The snapshot needs to store physical blocks only when the blocks change, so a backup of an unchanged file is a metadata-only operation.

• Snapshots use storage efficiently. A backup of a file with a single changed block requires only one additional version of the block to be stored—either the old version or new version of the block, depending on the snapshot technique.

Some disadvantages are as follows:

• Snapshots have no knowledge of an Oracle AI Database block structure, and thus cannot validate Oracle blocks.

• Because snapshots reside on the same storage array as the source database, they are vulnerable to storage failures and data corruptions. If the array is inaccessible, or if the storage contains data block corruptions, then the snapshots cannot be used for recovery.

• Restoring a snapshot in place voids all snapshots that were taken after it unless the snapshot is fully restored to an alternate location.

See Also: Oracle Database Backup and Recovery User’s Guide to learn more about using Storage Snapshot Optimization to take third-party snapshots of the database