Mechanism of Oracle Incremental Backups and RMAN Execution Procedures

In Oracle Database operations, reducing backup windows and saving storage capacity are common challenges. Oracle Incremental Backup is an efficient method that extracts only the data blocks that have changed since the previous backup.

This article provides a comprehensive guide for beginner to intermediate Oracle engineers, covering logical diagrams of incremental backups, specific execution procedures in RMAN (Recovery Manager), and the differences from cumulative increments.

Conclusion: Checklist for Incremental Backup Operations
Background and Basics: What is Incremental Backup?
[Diagram] Conceptual Image of Differential vs. Cumulative Increments
1. 1. Differential Incremental Backup
2. 2. Cumulative Incremental Backup
Procedures and Implementation: Executing Backups with RMAN
Execution Example and Log Explanation (19c)
Troubleshooting: Common Errors
Operational Considerations
FAQ
Summary

Conclusion: Checklist for Incremental Backup Operations

The following are the shortest steps to achieve efficient backup operations:

Take a Level 0 backup: This is the full backup that serves as the starting point (parent) for all incremental backups.
Run Level 1 backups regularly: Back up only the daily changes to save time and capacity.
Consider Block Change Tracking: This is an Enterprise Edition (EE) option that accelerates incremental reading.
Perform recovery validation: Use RESTORE DATABASE VALIDATE to confirm that the backups are valid.

Background and Basics: What is Incremental Backup?

An Oracle incremental backup does not copy the entire data file; instead, it is a feature that extracts only “data blocks that have changed since the previous backup.”

Quick Note: Level 0 and Level 1

In Oracle RMAN, the base point for increments is called “Level 0,” and subsequent changes are called “Level 1.” If you run a Level 1 backup without a Level 0 existing, a full backup is automatically performed.

[Diagram] Conceptual Image of Differential vs. Cumulative Increments

The primary difference lies in “from what point in time the changes are captured.”

1. Differential Incremental Backup

This captures only the changes since the most recent Level 0 or Level 1 backup.

[Conceptual Image of Differential Increment]
Mon [Lv0] : All data
Tue [Lv1] : Changes since Monday (D1)
Wed [Lv1] : Changes since Tuesday (D2)
Thu [Lv1] : Changes since Wednesday (D3)

At Recovery: [Lv0] + [D1] + [D2] + [D3] are all required.
=> Benefit: Daily backup time is minimized.

2. Cumulative Incremental Backup

This captures “all changes” since the most recent Level 0 backup every time.

[Conceptual Image of Cumulative Increment]
Mon [Lv0] : All data
Tue [Lv1] : Changes since Monday (C1)
Wed [Lv1] : Changes since Monday (C2)
Thu [Lv1] : Changes since Monday (C3)

At Recovery: [Lv0] + [C3] (only the latest one) is sufficient.
=> Benefit: Recovery is faster and simpler.

Procedures and Implementation: Executing Backups with RMAN

To perform incremental backups, use RMAN (Recovery Manager).

Prerequisites

Privileges: SYSDBA or SYSBACKUP privilege.
Mode: ARCHIVELOG mode recommended.
CDB/PDB: You can target all containers by connecting to CDB$ROOT.

1. Taking a Level 0 (Base) Backup

First, take the backup that serves as the “parent” for incremental operations.

-- Backs up all data blocks and creates the base for increments
RMAN> BACKUP INCREMENTAL LEVEL 0 DATABASE;

2. Taking a Level 1 (Differential) Backup

In daily operations, the default “differential” backup is executed.

-- Captures only changes since the previous Level 0 or 1
RMAN> BACKUP INCREMENTAL LEVEL 1 DATABASE;

3. Taking a Cumulative Incremental Backup

If you want to simplify recovery tasks, specify CUMULATIVE.

-- Captures "all changes" since the previous Level 0 collectively
RMAN> BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;

Execution Example and Log Explanation (19c)

The following is the log when a Level 1 backup is executed.

RMAN> BACKUP INCREMENTAL LEVEL 1 DATABASE;

Starting backup at 30-MAR-26
using channel ORA_DISK_1
channel ORA_DISK_1: starting incremental level 1 datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/u01/app/oracle/oradata/ORCL/system01.dbf
...
channel ORA_DISK_1: piece 1 completed
piece handle=/u01/app/oracle/product/19.0.0/dbhome_1/dbs/0v3huq6f_31_1_1 tag=TAG20260330T154622
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:07

Supplementary Note: When executing LEVEL 1, RMAN scans the entire data file to find changed blocks. To speed up this scan, please enable the “Block Change Tracking” feature available in Enterprise Edition.

Troubleshooting: Common Errors

ORA Error	Cause	Countermeasure
ORA-19606	Previous Level 0 not found	Take LEVEL 0 first.
ORA-19504	Insufficient disk space	Check free space in the FRA (Fast Recovery Area).
RMAN-06059	Missing logs	Run `CROSSCHECK ARCHIVELOG ALL;`.

Operational Considerations

Recovery Procedure: RMAN automatically combines the appropriate Level 0 and Level 1 backups for restoration. Users do not need to select files manually.
Pitfall: Password files and PFILEs are not included in RMAN backups, so they must be stored separately via OS copy or other means.
Reverting: If you ever want to revert backup settings, you can return to default values by using the CONFIGURE ... CLEAR command.

FAQ

Q: Can I use this in SE2 (Standard Edition 2)?

A: Yes, you can. However, scan acceleration (BCT) is exclusive to EE.

Q: Is Level 0 the same as a FULL backup?

A: The content is the same, but a FULL backup cannot serve as a base for increments. For incremental operations, always specify LEVEL 0.

Q: What changes when migrating to 23ai?

A: Basic RMAN syntax is inherited, but security features such as advanced automation and Immutable Backups have been enhanced.

Summary

Differential incremental backups protect daily data with minimum capacity.
Cumulative incremental backups reduce the number of files to apply during recovery.
The operational base must be taken as LEVEL 0; do not confuse it with FULL.
Periodically check backup health with RESTORE ... VALIDATE.

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

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