Skip Headers
Oracle® Database Backup and Recovery Advanced User's Guide
10g Release 2 (10.2)

Part Number B14191-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Feedback

Go to previous page
Previous
Go to next page
Next
View PDF

Backup Retention Policies

You can use the CONFIGURE RETENTION POLICY command to create a persistent and automatic backup retention policy. When a backup retention policy is in effect, RMAN considers backups of datafiles and control files as obsolete, that is, no longer needed for recovery, according to criteria that you specify in the CONFIGURE command. You can then use the REPORT OBSOLETE command to view obsolete files and DELETE OBSOLETE to delete them.

As you produce backups over time, older backups become obsolete as they are no longer needed to satisfy the retention policy. RMAN can identify the obsolete files for you, but it does not automatically delete them. You must use the DELETE OBSOLETE command to delete files that are no longer needed to satisfy the retention policy.

If you have a flash recovery area configured, however, then the database automatically deletes unnecessary files from the flash recovery area based on its internal disk quota rules. The disk quota rules are distinct from the backup retention policy rules, but the database will never delete files in violation of the retention policy to satisfy the disk quota.

The term obsolete does not mean the same as expired. A backup is obsolete when REPORT OBSOLETE or DELETE OBSOLETE determines, based on the user-defined retention policy, that it is not needed for recovery. A backup is considered expired only when RMAN performs a crosscheck and cannot find the file. In short, obsolete means "not needed," whereas expired means "not found."

From the perspective of a retention policy, a datafile backup is a full or level 0 backup of an individual datafile or control file. It does not matter whether the backup is a datafile image copy, a proxy copy, or part of a backup set. For datafile copies and proxy copies, if RMAN determines that the copy or proxy copy is not needed, then the copy or proxy copy can be deleted. For datafile backups in backup sets, RMAN cannot delete the backup set until all of the individual datafile backups within the backup set are obsolete.

Besides affecting full or level 0 datafile and control file backups, the retention policy affects archived redo logs and level 1 incremental backups. First, RMAN decides which datafile and control file backups are obsolete. Then, RMAN considers as obsolete all archived logs and incremental level 1 backups that are not needed to recover the oldest datafile or control file backup that must be retained.


Note:

RMAN cannot implement an automatic retention policy if backups are deleted by non-RMAN methods, for example, through the media manager's tape retention policy. The media manager should never expire a tape until all RMAN backups on that tape have been removed from the media manager's catalog.

There are two mutually exclusive options for implementing a retention policy: redundancy and recovery window. If no retention policy is configured by the user, then the REPORT OBSOLETE andDELETE OBSOLETE commands use a default retention policy of REDUNDANCY 1.

To configure a retention policy based on a recovery window, use the following command:

To configure a retention policy based on redundancy, use the following command:

You can also disable the retention policy completely, meaning that RMAN does not consider any backup to be obsolete. To do so, use the following command:

CONFIGURE RETENTION POLICY TO NONE;

Recovery Window

A recovery window is a period of time that begins with the current time and extends backward in time to the point of recoverability. The point of recoverability is the earliest time for a hypothetical point-in-time recovery, that is, the earliest point to which you can recover following a media failure. For example, if you implement a recovery window of one week, then this window of time must extend back exactly seven days from the present so that you can restore a backup and recover it to this point. You implement this retention policy as follows:

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

This command ensures that for each datafile one backup that is older than the point of recoverability must be retained. For example, if the recovery window is 7, then there must always exist one backup of each datafile that satisfies the following condition:

SYSDATE - BACKUP CHECKPOINT TIME >=  7

All backups older than the most recent backup that satisfied this condition are obsolete.

Assume the following retention policy illustrated in Figure 2-6. The retention policy has the following aspects:

  • The recovery window is 7 days.

  • Database backups are scheduled every two weeks on these days:

    • January 1

    • January 15

    • January 29

    • February 12

  • The database runs in ARCHIVELOG mode, and archived logs are saved on disk only as long as needed for the retention policy.

Figure 2-6 Recovery Window, Part 1

Description of bradv004.gif follows
Description of the illustration bradv004.gif

As illustrated in Figure 2-6, the current time is January 23 and the point of recoverability is January 16. Hence, the January 14 backup is needed for recovery, and so are the archived logs from log sequence 500 through 850. The logs before 500 and the January 1 backup are obsolete because they are not needed for recovery to a point within the window.

Assume the same scenario a week later, as depicted in Figure 2-7.

Figure 2-7 Recovery Window, Part 2

Description of bradv002.gif follows
Description of the illustration bradv002.gif

In this scenario, the current time is January 30 and the point of recoverability is January 23. Note how the January 14 backup is not obsolete even though a more recent backup (January 28) exists in the recovery window. This situation occurs because restoring the January 28 backup does not enable you to recover to the earliest time in the window, January 23. To ensure recoverability to any point within the window, you must save the January 14 backup as well as all archived redo logs from log sequence 500 to 1150.

Backup Redundancy

A redundancy-based retention policy specifies how many backups of each datafile must be retained. For example, you can specify:

CONFIGURE RETENTION POLICY TO REDUNDANCY 2;

Although the recovery window is the best practice for specifying a retention policy, it can complicate disk space usage planning because the number of backups that must be kept by the recovery window is not constant and depends on the backup schedule. Use the CONFIGURE RETENTION POLICY TO REDUNDANCY n command to implement a retention policy that maintains a constant number of backups of each datafile. RECOVERY WINDOW and REDUNDANCY-based retention policies are mutually exclusive.

The default retention policy is REDUNDANCY = 1, to maintain compatibility with the behavior of REPORT OBSOLETE in earlier RMAN releases. You can also run the following command to disable the retention policy altogether:

CONFIGURE RETENTION POLICY TO NONE;

If the retention policy is configured to NONE, then REPORT OBSOLETE and DELETE OBSOLETE do not consider any backups to be obsolete.

Batch Deletes of Obsolete Backups

Run the REPORT OBSOLETE command to determine which backups are currently obsolete according to the retention policy.

If you configure the retention policy to NONE, then RMAN does not consider any backups as obsolete. Consequently, RMAN issues an error when you run REPORT OBSOLETE without any other options and the retention policy is set to NONE.

A companion command, DELETE OBSOLETE, deletes all files which are obsolete according to the retention policy. You should run DELETE OBSOLETE periodically to minimize space wasted by storing obsolete backups. For example, you can run DELETE OBSOLETE in a weekly script.

You can also specify the REDUNDANCY or RECOVERY WINDOW options on the REPORT or DELETE commands, to overrride the configured retention policy.

The REPORT OBSOLETE and DELETE OBSOLETE commands work in two steps:

  1. For each datafile for which there are full backup, datafile copy, or level 0 incremental backups, RMAN identifies the oldest full or level 0 backup or copy that is not obsolete under the retention policy being tested. Any full backup, level 0 incremental backup, or datafile copy of a datafile older than the one identified in this step is considered obsolete.

  2. Any archived logs and level 1 incremental backups that are older than the oldest non-obsolete full backup are then obsolete because there is no full or level 0 backup to which they can be applied.


    See Also:


Exempting Backups from the Retention Policy

You may want to store a long-term backup, potentially offsite, for much longer than the time dictated by the retention policy. For example, you may make a database backup on the first day of every year to satisfy some regulatory requirement, independent of backups taken for your ongoing backup and recovery strategy.

Such long-term backups should be recorded in the RMAN repository, but they must be exempted from the retention policy because RMAN would quickly consider them obsolete, and they would be removed the next time the DELETE OBSOLETE command is used.

You can exempt a backup from the retention policy by using the KEEP option with the BACKUP command when you create the backup, or the KEEP option of the CHANGE command to exempt an existing backup. Note that backups exempted from the retention policy are still fully valid backups, which can be used in restore and recovery operations like any other if RMAN judges them to be the best choice available.

You can change the exempt status of a backup using the CHANGE... KEEP and CHANGE... NOKEEP commands. The NOKEEP option (default) indicates that the backup is not immune from the configured retention policy.

You can specify the LOGS option to save archived logs for a possible incomplete recovery of the long-term backup. When LOGS is specified, all logs more recent than the backup are kept as long as the backup is kept. In other words, KEEP UNTIL TIME... LOGS means that RMAN will keep all logs required to recover the backup as long as the backup is kept. If you specify NOLOGS, then RMAN does not keep the logs required to recover the backup. Note that if you use KEEP UNTIL TIME... with an inconsistent backup, you must use the LOGS option, or that backup will become unusable when the logs required to recover it are deleted as obsolete.

You can specify an end date using the UNTIL clause, or either specify that the backup should be kept FOREVER. If you specify UNTIL, then RMAN will not mark the backup as obsolete until after the UNTIL date has passed. Note that it is an error to specify KEEP FOREVER with the LOGS option, as this would require keeping all redo logs forever.

The following commands are examples of long-term backups:

# Creates a backup and exempts it from retention policy until last day of 2007
BACKUP DATABASE KEEP UNTIL TIME "TO_DATE('31-DEC-2007' 'dd-mon-yyyy')" NOLOGS;

# Specifies that backupset 2 is no longer exempt from the retention policy
CHANGE BACKUPSET 2 NOKEEP;

# Creates a backup that is indefinitely exempt from the retention policy
BACKUP TABLESPACE users KEEP FOREVER NOLOGS;

See Also:

Oracle Database Backup and Recovery Reference for CHANGE syntax

Relationship Between Retention Policy and Flash Recovery Area Rules

The RMAN status OBSOLETE is always determined in reference to a retention policy. For example, if a database backup is OBSOLETE in the RMAN repository, it is because it is either not needed for recovery to a point within the recovery window, or it is redundant.

If you configure a flash recovery area, then the database uses an internal algorithm to select files in the flash recovery area that are no longer needed to meet the configured retention policy. These backups have status OBSOLETE, and are eligible for deletion to satisfy the disk quota rules.

There is one important difference between the flash recovery area criteria for OBSOLETE status and the disk quota rules for deletion eligibility. Assume that archived logs 1000 through 2000, which are on disk, are needed for the currently enabled recovery window and so are not obsolete. If you back up these logs to tape, then the retention policy still considers the disk logs as required, that is, not obsolete. Nevertheless, the flash recovery area disk quota algorithm considers the logs on disk as eligible for deletion because they have already been backed up to tape. The logs on disk do not have OBSOLETE status in the repository, but they are eligible for deletion by the flash recovery area. Note, though, that the retention policy is never violated when determining which files to delete from the flash recovery area to satisfy the disk quota rules.