RMAN in Oracle Database 26ai: What Has Changed and Why It Matters

A practitioner's guide to the new encryption defaults, backup mobility, recovery catalog enhancements, and the features Oracle has quietly retired.

Executive Overview

Oracle Database 26ai delivers one of the most substantial refreshes to Recovery Manager (RMAN) in recent memory. The release strengthens encryption defaults, makes backups significantly more portable across storage classes, modernizes recovery catalog operations, and removes several long-standing features from the supported toolkit.

Most of these enhancements directly improve operational flexibility and security posture. A few, however, introduce subtle behavioral inconsistencies between the documentation and runtime metadata that administrators should verify in their own environments before relying on them in production.

This article distills the most consequential RMAN changes in 26ai — what is new, what is gone, what to validate, and how to adapt your operational playbooks accordingly.

1. Summary of RMAN Changes in 26ai

Before diving into details, the table below offers a high-level map of the changes covered in this article and their likely operational impact.

Change	Category	Operational Impact
Default backup encryption shifts toward AES256 XTS	Security	Stronger at-rest protection; verify runtime mode
Re-encrypt backups without restore via `BACKUP BACKUPSET`	Operations	Eliminates restore-and-rebackup cycles
Native SBT libraries bundled in Oracle Home	Integration	Faster cloud and tape onboarding
Cross-device backup migration via `INPUT DEVICE PARMS`	Mobility	Direct disk-to-cloud and cloud-to-ZDLRA flows
Catalog improvements (standby register, savepoint resync, auto-disconnect, `TERMINATE`)	Catalog	Reduced contention and friction in large estates
Data Recovery Advisor commands de-supported	Removal	Update monitoring and runbook scripts
`RECOVER ... SNAPSHOT TIME` de-supported in documentation	Removal	Adopt traditional hot-backup snapshot pattern
Database incarnations remain central to recovery	Continuity	No change — remains a critical concept

2. Stronger Backup Encryption Defaults

Among all the security-oriented updates in 26ai, the shift in default backup encryption is the one most administrators will notice first.

From CFB to XTS

Earlier Oracle releases commonly applied AES128 in CFB mode when encrypting RMAN backups. Oracle Database 26ai moves the recommended baseline to AES256 in XTS mode.

This is a deliberate, security-driven change. XTS was specifically designed to protect data at rest on storage media, while CFB was originally optimized for streaming data. For backup files persisted to disk, tape, or object storage, XTS is the more appropriate cipher mode.

When the New Default Activates

The new behavior becomes effective once the database compatibility level is raised:

COMPATIBLE >= 23.0.0

RMAN exposes the configured algorithm via:

RMAN> SHOW ENCRYPTION ALGORITHM;
CONFIGURE ENCRYPTION ALGORITHM 'AES256';

A Discrepancy Worth Knowing About

A subtle inconsistency exists between the documentation and the metadata exposed by the instance. The dynamic performance view below lists the algorithms RMAN considers available:

SELECT ALGORITHM_ID,
       ALGORITHM_NAME,
       ALGORITHM_DESCRIPTION,
       IS_DEFAULT,
       IS_RECOMMENDED
FROM   V$RMAN_ENCRYPTION_ALGORITHMS;

A representative output:

ID	Name	Description	Default	Recommended
1	AES128	AES 128-bit key, CFB mode	NO	NO
2	AES192	AES 192-bit key, CFB mode	NO	NO
3	AES256	AES 256-bit key, CFB mode	YES	NO
4	AES128	AES 128-bit key, XTS mode	NO	NO
6	AES256	AES 256-bit key, XTS mode	NO	YES

Observation. Documentation positions AES256 XTS as the new default, yet the metadata view continues to mark AES256 CFB with IS_DEFAULT=YES. IS_RECOMMENDED=YES sits with the XTS variant. This gap leaves the actual runtime behavior ambiguous.

Plausible explanations include:

The runtime encryption behavior changed but the metadata view was not updated.
The documentation moved ahead of the implementation.
Oracle internally maps AES256 to XTS without surfacing the mode through the existing flags.

RMAN currently does not expose the actual cipher mode used inside V$BACKUP_PIECE, which makes direct verification difficult. Administrators relying on a specific cipher mode for compliance reasons should validate behavior empirically.

Why no AES192 XTS? The XTS specification only supports 128-bit and 256-bit key sizes, so the absence of an AES192 XTS variant is by design rather than an Oracle limitation.

3. Re-Encrypting Existing Backups Without Restore

Before 26ai, changing the encryption profile of an existing backup typically meant a two-step ordeal: restore the backup, then back it up again under the desired algorithm. For large estates, this is expensive in both time and storage.

26ai removes that constraint. RMAN can now re-encrypt existing backup sets directly during a copy operation by leveraging the BACKUP BACKUPSET command. The original backup remains untouched while a new, re-encrypted copy is produced.

Worked Example: Encrypting an Existing Unencrypted Backup

Step 1 — Create an Unencrypted Backup

BACKUP TABLESPACE USERS
  TAG    'UNENCRYPTED_BACKUP'
  FORMAT '/backup/src_%U';

Step 2 — Verify Encryption Status

SELECT BS_KEY, ENCRYPTED
FROM   V$BACKUP_PIECE
WHERE  TAG = 'UNENCRYPTED_BACKUP';

Expected result:

BS_KEY	ENCRYPTED
22	NO

Step 3 — Re-Encrypt During Copy (Password-Based)

SET ENCRYPTION ON IDENTIFIED BY "StrongPassword123" ONLY;

BACKUP BACKUPSET 22
  FORMAT '/backup/dst_%U'
  TAG    'REENCRYPTED_COPY';

Step 4 — Verify the Re-Encrypted Copy

SELECT BS_KEY, ENCRYPTED
FROM   V$BACKUP_PIECE
WHERE  TAG = 'REENCRYPTED_COPY';

Expected result:

BS_KEY	ENCRYPTED
23	YES

Operational benefit. The original backup remains intact; the new copy is encrypted. No restore is required, and the I/O cost is roughly equivalent to a single backup operation rather than a full restore-plus-rebackup cycle.

Automatic Encryption-Mode Upgrade

When COMPATIBLE >= 23.0.0, RMAN automatically upgrades copied backups from CFB to XTS mode during such re-encryption operations. This makes the new feature a natural vehicle for modernizing legacy backup repositories during migration or consolidation work.

4. Transparent Encryption Mode

RMAN continues to support transparent encryption backed by the Oracle TDE keystore. The pattern is unchanged in spirit but worth restating in the context of the new defaults.

SET ENCRYPTION ON FOR BACKUP BACKUPSET;

BACKUP DEVICE TYPE sbt
  BACKUPSET ALL
  DELETE INPUT;

Prerequisites

The wallet or keystore must be open.
A TDE master key must be configured.

If the wallet is open but no master key has been configured, RMAN may surface errors such as:

ORA-19914
ORA-28361

Password-based encryption remains independent of TDE and continues to function without a keystore — useful for ad-hoc encrypted exports or environments where TDE is not in scope.

5. Native SBT Library Integration

Cloud and tape integrations historically required administrators to download separate media management libraries, match versions to the Oracle Home, and resolve compatibility issues case by case. 26ai materially reduces that friction by bundling several SBT libraries directly inside Oracle Home.

Alias	Target
`oracle.oci`	OCI Object Storage
`oracle.zdlra`	Zero Data Loss Recovery Appliance
`oracle.osbws`	Amazon S3
`oracle.azure`	Azure Blob Storage

The practical effect is that hybrid and multi-cloud backup topologies can be stood up faster and with fewer moving parts. It also sets up the backup-mobility scenarios discussed next.

6. Backup Mobility Across Storage Tiers

26ai improves the portability of backups across storage classes through the INPUT DEVICE PARMS clause, which allows RMAN to read from one device type and write to another within a single operation.

Example: OCI Object Storage to Local Disk

RUN {
  ALLOCATE CHANNEL c1 DEVICE TYPE DISK
    INPUT DEVICE PARMS='SBT_LIBRARY=oracle.oci';

  BACKUP BACKUPSET ALL;
}

Example: OCI Object Storage to Recovery Appliance

RUN {
  ALLOCATE CHANNEL c1 DEVICE TYPE SBT
    PARMS='SBT_LIBRARY=oracle.zdlra'
    INPUT DEVICE PARMS='SBT_LIBRARY=oracle.oci';

  BACKUP BACKUPSET ALL;
}

What This Enables

Migrating backup repositories between storage tiers without intermediate restores.
Re-encrypting backups while they move — combine with the re-encryption pattern in §3.
Consolidating backup infrastructure across cloud and on-premises systems.
Modernizing older backup formats and ciphers in a single pass.

7. Recovery Catalog Improvements

The recovery catalog also receives meaningful operational upgrades in 26ai — mostly aimed at large environments where contention and synchronization costs become real constraints.

Standby Database Registration

RMAN can now register a physical standby database directly without requiring connectivity to the primary. This simplifies Data Guard environments where the standby sits in a network zone isolated from the primary.

Incremental Resynchronization Rollback

Previously, a failed catalog resynchronization would roll back the entire operation. 26ai introduces savepoint-based rollback so partial progress can be preserved. Benefits include:

Faster retries after transient failures.
Reduced overhead during catalog synchronization windows.
Better behavior under load on large RMAN catalogs.

Automatic Catalog Disconnect During Backups

RMAN now disconnects from the recovery catalog while a backup operation is actively running. This reduces session contention, lowers the risk of catalog locking, and limits interference between concurrent backup jobs — all particularly relevant in busy enterprise estates.

New TERMINATE Commands

Two new commands give administrators a controlled way to clear catalog sessions during upgrades or maintenance windows:

TERMINATE BLOCKING CONNECTED USERS
TERMINATE WAITING  CONNECTED USERS

Both require maintenance mode:

SET CATALOG MAINTENANCE ON;

8. Removed and De-Supported Features

Several long-standing RMAN capabilities are now removed or officially unsupported. Treat these as runbook updates, not just informational notes.

Data Recovery Advisor Removed

The following commands are de-supported in 26ai, and Oracle has not provided a direct replacement:

LIST    FAILURE
ADVISE  FAILURE
REPAIR  FAILURE
CHANGE  FAILURE

If your operational tooling, automated recovery flows, or monitoring scripts invoke any of these commands, review and revise them before upgrading.

RECOVER ... SNAPSHOT TIME

RECOVER ... SNAPSHOT TIME was deprecated in earlier releases and is now documented as de-supported in 26ai. Example syntax:

RECOVER DATABASE
  UNTIL TIME    "TO_DATE('2026-04-03 15:00:00','YYYY-MM-DD HH24:MI:SS')"
  SNAPSHOT TIME "TO_DATE('2026-04-03 14:30:00','YYYY-MM-DD HH24:MI:SS')";

Behavioral note. The current parser may still accept this syntax without raising a de-support error. This suggests the documentation has been updated ahead of full runtime enforcement. Do not rely on this behavior — it is on a deprecation path and may begin failing in a future patchset.

Recommended Replacement Pattern

Oracle recommends the traditional hot-backup approach when integrating with third-party storage snapshots:

ALTER DATABASE BEGIN BACKUP;

-- Take the storage-level snapshot here.

ALTER DATABASE END BACKUP;

Archived redo logs should then be backed up separately and shipped alongside the snapshot.

9. Database Incarnations: Still Essential

Database incarnations are not new in 26ai, but they remain one of the most important — and most often misunderstood — concepts in advanced recovery operations. A new incarnation is created whenever:

ALTER DATABASE OPEN RESETLOGS;

Each incarnation represents a distinct recovery timeline.

Inspecting Incarnations

SELECT INCARNATION#,
       RESETLOGS_CHANGE#,
       RESETLOGS_TIME,
       STATUS
FROM   V$DATABASE_INCARNATION
ORDER  BY INCARNATION#;

A representative output:

INCARNATION#	RESETLOGS_CHANGE#	STATUS
1	1	PARENT
2	122348501	CURRENT

RMAN exposes the same information through:

LIST INCARNATION OF DATABASE;

Recovering Across Incarnations

To recover into an earlier incarnation, redirect the recovery target:

RESET DATABASE TO INCARNATION 1;

The database must be mounted, not open. Otherwise RMAN raises:

ORA-19910: cannot change recovery target incarnation in control file

Once the target incarnation has been set, RMAN can restore and recover backups from the older timeline, provided the required archived redo logs remain available. This mechanism enables reliable recovery across RESETLOGS boundaries and remains one of RMAN's most powerful capabilities.

10. Final Thoughts and Adoption Guidance

Oracle Database 26ai represents a meaningful step forward for RMAN. The improvements cluster around four themes that reinforce each other:

Stronger encryption through AES256 XTS as the recommended baseline.
Backup portability via cross-device migration and bundled SBT libraries.
Simpler cloud integration with first-class support for OCI, S3, Azure Blob, and ZDLRA.
Better recovery catalog scalability through savepoints, auto-disconnect, and new termination commands.

The new re-encryption capability and cross-device backup mobility stand out as particularly valuable: together, they let organizations modernize backup infrastructure or migrate between storage platforms without expensive restore-and-rebackup cycles.

Pre-Adoption Checklist

Confirm the actual cipher mode applied at runtime once COMPATIBLE is raised — do not assume documentation matches metadata.
Audit operational scripts for any reference to Data Recovery Advisor or RECOVER ... SNAPSHOT TIME and replace before upgrade.
Review encryption profiles across existing backup repositories and plan a re-encryption pass for legacy AES128/CFB content.
Validate end-to-end recovery flows in a non-production environment, including incarnation handling, before production cutover.

Conclusion

26ai modernizes RMAN substantially, but a few implementation details — particularly around encryption defaults and the de-supported snapshot syntax — still require firsthand verification in live environments. Treat the upgrade as a strong opportunity to refresh backup security and portability, and pair it with a careful runbook review to retire the features Oracle has now retired.

thnaks for reading :)

BR,

SYED ZAHEER