Archive Backups Using the Oracle RMAN BACKUP KEEP Command

The BACKUP KEEP command in Oracle Recovery Manager (RMAN) is a powerful feature for managing specific backups outside the scope of normal retention policies and protecting them for long periods.

Typically, RMAN marks old backups as “OBSOLETE” and targets them for deletion based on the configured recovery window or redundancy. However, this command proves its true value when you need to ensure a backup is not automatically deleted—such as for year-end audits, legal requirements, or snapshots taken before major system changes.

Conclusion: Quick Steps for Long-Term Storage Backups
1. How the BACKUP KEEP Command Works
2. Implementation and Execution Examples: Long-Term Storage Scenarios
1. 2.1 Keeping Backups for a Specific Period (KEEP UNTIL)
2. 2.2 Keeping Backups Indefinitely (KEEP FOREVER)
3. Retention Settings Specialized for Archivelogs
1. 3.1 Backing Up a Specific Past Range
2. 3.2 Specifying by SCN (System Change Number)
4. Management and Deletion of Kept Backups
FAQ: Frequently Asked Questions
Summary

Conclusion: Quick Steps for Long-Term Storage Backups

To protect specific backups regardless of policy, follow these steps:

Planning: Determine the retention period (how long it needs to be kept).
Execution: Run the BACKUP ... KEEP command with a specified duration or an indefinite term.
Management: Use the LIST command to verify expiration dates and manually delete them once they are no longer needed.

1. How the BACKUP KEEP Command Works

Backups taken using the BACKUP KEEP command have their “retention period” specially managed within the control file.

Bypassing Retention Policy: Regardless of the configured RETENTION POLICY (e.g., a 30-day retention), these backups will not become OBSOLETE until the specified deadline.
Archival Backup: In addition to the entire database, the required archivelogs and control files are protected as a complete set for recovery.

2. Implementation and Execution Examples: Long-Term Storage Scenarios

2.1 Keeping Backups for a Specific Period (KEEP UNTIL)

RMAN will not consider this backup “obsolete” until the specified date arrives.

-- Backup the entire database with a setting to keep it for 30 days
RMAN> BACKUP AS BACKUPSET DATABASE KEEP UNTIL TIME 'SYSDATE+30';

UNTIL TIME: Defines the expiration date. Once the deadline passes, the backup returns to the management of the normal retention policy.

2.2 Keeping Backups Indefinitely (KEEP FOREVER)

Used for data with legal storage obligations where automatic deletion must never occur. Note: This option requires the use of a Recovery Catalog (external database).

-- Keep the database indefinitely, including all archivelogs
RMAN> BACKUP AS BACKUPSET DATABASE PLUS ARCHIVELOG KEEP FOREVER;

3. Retention Settings Specialized for Archivelogs

These examples demonstrate how to preserve only specific ranges of logs for archival purposes.

3.1 Backing Up a Specific Past Range

-- Take only the archivelogs from the past 7 days and keep them for 1 year
RMAN> BACKUP AS BACKUPSET ARCHIVELOG FROM TIME 'SYSDATE-7' UNTIL TIME 'SYSDATE' 
      KEEP UNTIL TIME 'SYSDATE+365';

3.2 Specifying by SCN (System Change Number)

-- Keep logs from a specific SCN onwards for 180 days
RMAN> BACKUP AS BACKUPSET ARCHIVELOG FROM SCN 100000 
      KEEP UNTIL TIME 'SYSDATE+180';

4. Management and Deletion of Kept Backups

4.1 Verifying Backup Status

Check which backups are set to be kept and for how long.

-- Display a summary of backups with KEEP settings
RMAN> LIST BACKUP SUMMARY;

-- Display detailed information only for database KEEP backups
RMAN> LIST BACKUP OF DATABASE KEEP;

4.2 Forced Deletion when No Longer Needed

If a manual deletion is required before the retention period ends (e.g., due to storage capacity), use the FORCE option.

-- Forcefully delete a specific backupset (e.g., number 123)
RMAN> DELETE FORCE BACKUPSET 123;

Operational, Monitoring, and Security Considerations

Risk of Storage Depletion: Since KEEP backups are excluded from RMAN’s automatic cleanup, they will continue to consume disk space if left unmanaged.
Catalog Requirements: When using KEEP FOREVER, the target database control file cannot store this information indefinitely. You must use a Recovery Catalog.
Integrity Verification: It is recommended to run CROSSCHECK BACKUP; periodically to ensure files haven’t been deleted at the OS level.

FAQ: Frequently Asked Questions

Q: Will the backup be deleted immediately after the KEEP UNTIL deadline expires? A: No. The moment the deadline expires, it becomes subject to the normal RETENTION POLICY. If it falls outside that policy, it will then be included in subsequent REPORT OBSOLETE or DELETE OBSOLETE commands.

Q: Can I use this in Standard Edition 2 (SE2)? A: Yes, it is available. However, without a Recovery Catalog, you cannot specify KEEP FOREVER. Additionally, because the control file depends on CONTROL_FILE_RECORD_KEEP_TIME, be cautious when specifying long UNTIL TIME durations.

Q: Are archivelogs automatically included when backing up with this command? A: If you specify DATABASE PLUS ARCHIVELOG, the logs required to bring that backup to a recoverable state will be saved as a set.

Summary

BACKUP KEEP is a feature that overrides normal retention rules to protect backups.
Use UNTIL TIME for timed expiration and FOREVER for indefinite storage.
Periodically check kept backups using LIST BACKUP ... KEEP.
Since they are not automatically deleted, plan storage capacity management carefully.

This article is based on Oracle Database 19c (screens and default values may differ in other versions).

[reference]
Oracle Database Backup and Recovery Reference, 19c