Managing Oracle database backups often means balancing recoverability requirements against ever-growing disk consumption. A misconfigured or absent RMAN retention policy can cause both storage overruns and recovery failures. How do you ensure you keep only what you need—and safely remove the rest? This is where the RMAN retention policy comes in. With proper settings, you automate backup cleanup, save storage space, and guarantee your ability to restore data when it matters most. Let’s break down how RMAN retention policy works from basics to advanced use cases.
What Is RMAN Retention Policy?
The RMAN retention policy defines rules for Oracle Recovery Manager (RMAN) about how long to keep backups and how many copies to retain before considering them obsolete. Obsolete backups are those no longer needed for recovery based on your chosen criteria—either a set number of copies or a time window.
By default, RMAN keeps only one backup of each datafile (redundancy 1). You can adjust this setting as your needs change. The retention policy applies not just to full or level 0 datafile backups but also affects control file backups, incremental backup, and archived redo logs once they are no longer required for point-in-time recovery.
Why Use an RMAN Retention Policy?
Without a clear retention policy in place, old backups accumulate quickly—filling up valuable disk space or even causing outages if storage runs out unexpectedly. Manual deletion is risky; deleting the wrong files could leave you unable to recover after a failure.
A well-set retention policy automates this process so you always have enough valid backups for safe recovery—but never more than necessary. This reduces costs by freeing up storage regularly, simplifies ongoing management tasks, and lowers the risk of accidental data loss due to human error or oversight.
Isn’t it better to let Oracle handle routine cleanup so you can focus on higher-value work?
Types of RMAN Retention Policies
RMAN offers two main types of retention policies: redundancy-based and recovery window-based policies. You may use only one at any given time.
If no explicit policy is set, RMAN defaults to redundancy 1—keeping just the most recent backup copy per datafile. Disabling the retention policy means that no backup will ever be marked as obsolete by RMAN; manual intervention becomes necessary in such cases.
Choosing between these options depends on your business needs: do you want predictable numbers of copies (redundancy), or do you need guaranteed coverage over a specific period (recovery window)?
How to Set RMAN Retention Policy by Redundancy?
Redundancy-based policies tell RMAN exactly how many complete sets of each datafile’s backup should be kept at all times—regardless of their age.
First connect to your Oracle database using Recovery Manager (RMAN). Then configure redundancy with:
CONFIGURE RETENTION POLICY TO REDUNDANCY n;
Replace n with your desired number of copies—for example:
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
Setting REDUNDANCY 2 ensures there are always at least two recoverable backup sets per datafile before older ones become obsolete. Make sure your schedule allows enough full backups—and that your storage can support keeping multiple generations safely.
After configuring redundancy:
REPORT OBSOLETE;
DELETE OBSOLETE;
SHOW RETENTION POLICY;
You may reset back to default settings using:
CONFIGURE RETENTION POLICY CLEAR;
Or disable automatic obsolescence marking entirely with:
CONFIGURE RETENTION POLICY TO NONE;
How to Set RMAN Retention Policy by Recovery Window?
A recovery window-based policy preserves all files needed for point-in-time recovery within a defined period measured in days—not simply by count but by actual coverage span.
Connect via RMAN as usual then run:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF n DAYS;
For example—to keep everything needed for restores going back fifteen days:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 15 DAYS;
This tells Oracle: “Keep every piece required so I can restore my database as it was at any moment during these last fifteen days.” Any older files not essential for this purpose become obsolete according to the new rule.
Note: The recovery window counts backward from today’s date; if an old level-0 full backup is still required because incremental changes depend on it within this period—it stays! Sometimes this means retaining some files much older than ‘n’ days if they’re part of an active chain supporting recent restores.
To review which items now qualify as obsolete under this scheme:
REPORT OBSOLETE;
And clean them up with:
DELETE OBSOLETE;
Check current settings anytime using:
SHOW RETENTION POLICY;
Need more or less history? Just re-run CONFIGURE with a different value whenever requirements change.
Enterprise-Level Oracle Backup Made Simple with Vinchin Backup & Recovery
Beyond native tools like RMAN, organizations seeking streamlined enterprise protection should consider Vinchin Backup & Recovery—a professional solution designed specifically for robust database environments such as Oracle alongside MySQL, SQL Server, MariaDB, PostgreSQL, PostgresPro, and TiDB. For Oracle users in particular, Vinchin Backup & Recovery delivers features including advanced source-side compression, incremental backup capabilities tailored for efficient storage use over timeframes you define via flexible data retention policies—all managed through batch scheduling across multiple databases simultaneously while leveraging multi-level compression strategies where supported.
The intuitive web console makes safeguarding Oracle databases straightforward:
Step 1. Select the Oracle database to back up
Step 2. Choose the backup storage
Step 3. Define the backup strategy
Step 4. Submit the job
Vinchin Backup & Recovery is trusted globally by enterprises seeking reliable protection—with top ratings worldwide—and offers a risk-free full-featured trial lasting sixty days so you can experience its power firsthand before committing further investment.
RMAN Retention Policy FAQs
Q1: How do I view my current RMAN retention settings?
A1: Run SHOW RETENTION POLICY; in an open RMAN session—the result displays active configuration details instantly.
Q2: What does disabling my retention policy mean?
A2: When set with CONFIGURE RETENTION POLICY TO NONE, no automatic obsolescence occurs—you must manually track which files are safe for removal yourself.
Q3: How do I clean up missing (“expired”) versus unnecessary (“obsolete”) backups?
A3: Run CROSSCHECK BACKUP, then DELETE EXPIRED BACKUP, followed by DELETE OBSOLETE—this sequence updates catalog records before deleting unused physical files safely.
Q4: Will running DELETE OBSOLETE remove archived redo logs too?
A4: Yes—it deletes both outdated archive logs plus unneeded full/incremental/control file backups unless filtered further by command options provided in documentation guidelines.
Q5: Can I automate regular cleanup without manual intervention?
A5: Yes—schedule an OS-level task calling an .rman script containing maintenance commands such as CROSSCHECK BACKUP DELETE EXPIRED DELETE OBSOLETE NOPROMPT.
Conclusion
By implementing either redundancy-based or recovery-window policies—and automating regular cleanup—you gain robust control over Oracle backup lifecycles while minimizing risk from human error or wasted resources. Vinchin makes managing complex enterprise environments even easier through its streamlined interface.
Try Vinchin today for hassle-free protection!
