Create RMAN Incremental Backups in Oracle 26ai

Oracle Recovery Manager (RMAN) creates incremental physical backups by copying changed data-file blocks. An incremental strategy begins with a level 0 baseline and continues with level 1 backups. During recovery, RMAN can restore the baseline, apply the required level 1 backups, and then apply archived redo to reach the requested recovery point.

This lesson replaces original Export's retired INCTYPE=INCREMENTAL and INCTYPE=CUMULATIVE workflow. Oracle Data Pump Export does not provide an RMAN-style backup chain. A Data Pump QUERY can filter logical rows, and FLASHBACK_TIME can select a consistent logical snapshot, but neither feature creates a physical incremental backup.

Incremental backups can reduce repeated data-file work, network traffic, and backup duration when the changed-block rate is low. They do not eliminate archived redo, control-file and SPFILE protection, encryption keys, independent backup copies, retention planning, or restore testing.

Backup type	Blocks included	Role in recovery
RMAN full backup	Blocks required by the full backup rules for the selected files	Not a parent for later level 1 backups
Incremental level 0	All data blocks containing data in the selected files	Baseline for later level 1 backups
Differential level 1	Blocks changed since the most recent level 1 or level 0	Default level 1; may form a longer recovery chain
Cumulative level 1	Blocks changed since the most recent level 0	The latest cumulative can replace earlier level 1 sets during recovery
Data Pump filtered export	Logical rows selected by an application-defined query	Not part of the RMAN recovery chain

A level 0 backup can be a backup set or an image copy. A level 1 backup is a backup set. A full RMAN backup and a level 0 may contain similar data-file content, but only the level 0 belongs to the incremental chain. RMAN cannot convert an existing full backup into a level 0 parent.

Incremental levels apply to data files. Archived redo logs, the control file, and the SPFILE are not incrementally backed up. They remain separate recovery assets that must be captured and retained according to the required recovery window.

An incremental schedule is a recovery design, not merely a smaller backup command. Start with the recovery-point objective (RPO), recovery-time objective (RTO), protected CDB and PDB scope, retention period, changed-block rate, archived-redo volume, and the throughput of the selected backup media.

Differential level 1 backups usually minimize daily backup volume because each backup begins at the latest incremental parent. Recovery may need the level 0 and several differential sets. Cumulative level 1 backups normally grow throughout the cycle because each one repeats every change since the level 0, but recovery can use the latest cumulative set after restoring the baseline.

Schedule	Backup behavior	Recovery tradeoff
Level 0 plus differential level 1	Each level 1 captures changes since the latest incremental	Small daily sets; recovery may apply several level 1 sets
Level 0 plus cumulative level 1	Each level 1 captures changes since the latest level 0	Growing daily sets; recovery normally needs the latest cumulative
Mixed level 1 schedule	Differential backups plus planned cumulative checkpoints	Balances daily size with a controlled maximum chain length

Do not assume that a seven-day cycle is correct for every database. Measure backup time, restore time, media retrieval, and redo application under realistic conditions. A schedule that creates tiny daily backups can still miss its RTO if recovery must retrieve and apply too many sets.

Consider an illustrative sequence that begins with a level 0 at checkpoint L0. Application activity then changes blocks during three successive intervals, identified here as A, B, and C. These labels describe changed-block groups, not Oracle object or backup names.

Run	Differential level 1	Cumulative level 1
Baseline	Level 0 copies the baseline data blocks at L0
After interval A	Contains A	Contains A
After interval B	Contains B	Contains A and B
After interval C	Contains C	Contains A, B, and C

To recover through interval C with the differential strategy, RMAN may apply the level 0 followed by the A, B, and C differential sets. With the cumulative strategy, it can apply the level 0 and the latest cumulative containing A, B, and C. In both cases, archived redo advances the restored files from the applicable backup checkpoint to the exact recoverable endpoint.

Real backups do not divide changes into tidy equal intervals. A block can change many times, databases can add data files, a backup can fail, and media can become temporarily unavailable. RMAN uses checkpoint and incremental-start SCNs plus repository metadata to construct a valid chain. The example is a reasoning model, not permission to delete a set based only on its position in the table.

A level 1 backup is useful only while RMAN can reach a valid parent and the required recovery endpoint. Retention must preserve the baseline, every required child, archived redo, control-file and SPFILE backups, and any external keys or configuration. Losing the smallest file in the chain can make a much larger collection unusable for the intended recovery.

An illustrative recovery-window policy is:

RMAN> CONFIGURE RETENTION POLICY
2>   TO RECOVERY WINDOW OF 14 DAYS;

The value must come from business and operational requirements; fourteen days is not a default recommendation. RMAN uses the policy to determine which backups are required to maintain recoverability within the window and which have become obsolete. Inspect the result without deleting anything:

RMAN> REPORT OBSOLETE;

Obsolete means no longer required by the configured RMAN retention calculation. It does not automatically mean that immediate deletion is safe under legal holds, ransomware recovery, offsite-copy requirements, standby dependencies, export retention, or organizational policy. Review why each backup is reported and confirm that another usable copy exists in the required failure domain before authorizing cleanup.

Keep recovery copies independent from the active database and from one another when the threat model requires it. Separate storage, credentials, administrative authority, and deletion paths can prevent one hardware failure or compromised account from destroying production and every backup. Periodically test the copy that would actually be used after a site or storage loss, including its retrieval time and decryption dependencies.

For a whole-CDB incremental backup, connect RMAN to the CDB root with a common account granted SYSBACKUP or an approved equivalent. The following command assumes approved local operating-system authentication and that the operating-system environment identifies the intended CDB:

rman target /

Do not place a database password in a command or script. Confirm the target identity and container before starting. RMAN can protect selected PDBs, but a PDB backup is not a whole-CDB backup, and archived redo is managed at the CDB level.

Review the existing RMAN configuration:

RMAN> SHOW ALL;

The online workflow requires ARCHIVELOG mode. Also verify control-file autobackup, the retention policy, device and channel configuration, backup destination, available capacity, media credentials, archived-redo handling, and access to the TDE keystore and other external recovery assets.

A database in NOARCHIVELOG mode cannot create an incremental backup while open. RMAN can make an incremental after a consistent shutdown while the database is mounted, but that path requires downtime and cannot provide the same media-recovery range.

Create the intended baseline explicitly:

RMAN> BACKUP INCREMENTAL LEVEL 0 DATABASE
2>   TAG 'WEEKLY_LEVEL_0';

Level 0 copies the baseline data blocks and becomes the parent for later level 1 backups. It must scan the data files even when block change tracking is enabled. The tag helps identify the generation in RMAN listings, but it is not a filename, retention exemption, independent copy, or guarantee of recoverability.

If a usable level 0 does not exist in the current or parent database incarnation, RMAN can respond to a level 1 request by creating a level 0. Do not depend on that fallback in a production schedule. Create the baseline deliberately, verify its scope and status, and make failures visible before daily level 1 jobs begin.

An incremental data-file backup does not replace archived redo. When the configured output form and root-connected CDB scope support it, an integrated backup can include archived logs:

RMAN> BACKUP INCREMENTAL LEVEL 0 DATABASE
2>   PLUS ARCHIVELOG;

PLUS ARCHIVELOG coordinates log switches and archived-log backups around the data-file backup. A site can instead use a separately coordinated archived-log schedule. In either case, retain enough redo to reach every promised recovery point. Do not add DELETE INPUT until the recovery, standby, additional-copy, and deletion policies have been tested together.

Differential is the default level 1 type:

RMAN> BACKUP INCREMENTAL LEVEL 1 DATABASE
2>   TAG 'DAILY_LEVEL_1_DIFF';

RMAN copies blocks changed since the most recent available level 1 or level 0. If the baseline is the only incremental parent, the first differential captures changes since that level 0. The next differential normally begins from the preceding level 1 checkpoint.

This design can produce small daily sets when relatively few blocks change. During recovery, however, RMAN may need the level 0, multiple level 1 sets, and archived redo. Every required parent, backup piece, key, credential, and media path must remain available. Daily job success does not prove that the complete chain is intact.

Specify CUMULATIVE when each level 1 should contain all block changes since the latest level 0:

RMAN> BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE
2>   TAG 'DAILY_LEVEL_1_CUM';

A cumulative normally grows during the baseline cycle because it repeats changes already contained in earlier cumulative backups. In exchange, RMAN can recover from the level 0 and the latest usable cumulative level 1 before applying the required redo. Fewer level 1 sets can reduce recovery work and media retrieval.

Do not immediately discard earlier backups merely because a new cumulative completed. The RMAN retention policy, available copies, recovery window, archived redo, validation status, and tested restore plan determine when a generation is obsolete. A newly written set is not a safe replacement until its recovery role has been verified.

Without block change tracking, RMAN may scan each data file to identify blocks changed since the incremental start SCN. Block change tracking records changed-block information in a small binary file, allowing many level 1 backups to avoid scanning unchanged areas. It is disabled by default.

If the database uses Oracle managed files for this purpose, first verify the configured destination:

SHOW PARAMETER db_create_file_dest

Enable block change tracking from an authorized SQL session while the database is open or mounted:

ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;

Verify the status and file:

SELECT status, filename, bytes
FROM v$block_change_tracking;

The simple ALTER DATABASE form creates an Oracle managed change-tracking file when DB_CREATE_FILE_DEST is configured. A DBA can choose an explicit approved location instead. In Oracle RAC, the file must reside on shared storage accessible from every node.

Block change tracking improves scanning efficiency; it does not alter which changed blocks a valid backup must contain. RMAN uses it for incremental levels greater than 0, not for the level 0 scan. The file retains change information covering the eight most recent backups. When the required baseline falls outside that bitmap history, RMAN can lose some or all of the expected scanning benefit.

RMAN does not back up and restore the block change tracking file. After a restore or recovery causes tracking to reset, Oracle begins building new history. Enabling the feature on a physical standby also has Active Data Guard licensing and managed-recovery requirements that are outside this lesson.

List the repository records after every scheduled operation:

RMAN> LIST BACKUP SUMMARY;
RMAN> LIST BACKUP OF DATABASE;

In the summary, the LV column identifies level 0, level 1, a full backup, or an archived-log backup. The status column shows whether a backup is available, unavailable, or expired. Confirm that every intended data file has a usable level 0 and that subsequent level 1 backups match the scheduled type and completion window.

Also verify archived-redo coverage, control-file and SPFILE autobackups, storage location, independent copies, TDE keys, and media credentials. A repository row records what RMAN knows; LIST does not read every block in every backup piece. Likewise, CROSSCHECK synchronizes repository status with recorded accessibility but does not validate backup contents.

Make RMAN select and read the backup inputs it would use for a database restore without writing restored data files:

RMAN> RESTORE DATABASE VALIDATE;

Run validation through the intended disk, tape, cloud, or media-manager path. Review every warning and error. Validation increases confidence that the selected pieces are available, readable, and not corrupt, but it does not prove that every archived log, key, credential, network route, or external configuration will be ready during an emergency.

Periodically restore and recover the database to an isolated destination. Confirm that RMAN can locate the correct level 0, apply the necessary level 1 sets, apply archived redo to the intended endpoint, use the TDE keystore, and open the recovered database. Measure elapsed time against the RTO and the achieved endpoint against the RPO.

The oldest required parent is a critical part of the chain. A successful daily level 1 cannot compensate for a missing level 0, unavailable backup piece, lost key, expired credential, missing archived redo log, or untested recovery procedure.

Oracle also supports incrementally updated backups. This advanced strategy begins with a level 0 data-file image copy, creates level 1 differential backup sets by using FOR RECOVER OF COPY, and periodically applies the level 1 changes to the copy with RECOVER COPY.

The rolling copy can reduce restore work because the data-file copy is repeatedly brought forward. Its command order, tags, recovery lag, storage capacity, archived redo, and retention behavior require a dedicated design. Do not confuse it with an ordinary level 0/level 1 backup-set schedule, Recovery Appliance incremental-forever protection, or Data Pump exports.

A table-specific Data Pump QUERY can extract rows satisfying an application predicate. That operation does not automatically capture deleted rows, every schema change, or dependencies outside the selected data. A global query must also be valid for every table to which Data Pump applies it. Repeated execution does not create a physical recovery chain.

FLASHBACK_TIME and FLASHBACK_SCN select an SCN for a consistent logical export; they do not identify changes since an earlier dump. Tablespace mode selects logical export scope; it does not compare data-file blocks with a previous backup. Use these features for their documented Data Pump purposes, not as replacements for RMAN incremental backup and recovery.

The following existing quiz reviews the Export concepts introduced earlier in this module. It is separate from the RMAN level 0 and level 1 workflow taught in this lesson:

Export Utility - Quiz

The quiz should be interpreted using current Data Pump terminology. Original exp, INCTYPE, or claims that Data Pump provides incremental physical backup do not describe Oracle AI Database 26ai.

In the next lesson, you will learn how to perform a direct path export.