Oracle RMAN Backup Sets and Incremental Backups

Oracle Recovery Manager, or RMAN, supports two principal physical backup formats: backup sets and image copies. A backup set is the default output of the RMAN BACKUP command unless an image-copy format is configured or requested. This lesson concentrates on backup sets. Lesson 7 examines image copies.

Backup sets remain central to Oracle AI Database 26ai. They can be written through DISK channels to server-accessible storage or through SBT channels to compatible media-management software or an Oracle native library. RMAN can apply compression and encryption to backup sets, divide their output into pieces, and create full or incremental data-file backups in this format.

BACKUP DATABASE;

This simple command normally creates one or more backup sets on the configured default device. It does not create an operating-system copy of every database file, and the resulting binary files should not be manipulated as though they were ordinary data files. RMAN records their metadata in the target control file and, when used, the recovery catalog.

A backup set is an RMAN-specific logical structure and the smallest unit of an RMAN backup. It contains backup data and metadata in a format that RMAN creates and interprets. A backup piece is one physical binary file belonging to a set. A set contains one or more pieces, and it contains one piece by default.

Term	Meaning	Operational consequence
Backup set	RMAN-specific logical container for backup data.	RMAN records and selects the set during backup, restore, and recovery work.
Backup piece	Physical binary file that belongs to one backup set.	Filesystem, media, transfer, and piece-size limits apply to the physical file.
Input file	Data file, archived redo log, control file, or SPFILE whose contents are protected.	RMAN packages the applicable contents into one or more sets.
Channel	Target-database server session that performs backup or restore input and output.	Parallel channels generally create or read multiple sets concurrently.
Image copy	File-for-file copy recorded in the RMAN repository.	It is not a backup set and cannot use every backup-set feature.

A piece is not an independent copy of every object in its set. If RMAN creates several pieces for one set, restore and recovery can require all applicable pieces. Losing one required piece can make the set unusable for the data stored in that piece. Repository records identify the relationship, but the repository does not contain the physical backup data.

RMAN can create backup sets that protect data files, archived redo logs, control files, or the server parameter file, known as the SPFILE. An important restriction is that RMAN never combines data files and archived redo logs in the same backup set. A command can still produce both categories during one job:

BACKUP DATABASE PLUS ARCHIVELOG;

PLUS ARCHIVELOG does not mix database blocks and archived-log bytes in one set. RMAN archives the current redo as required, backs up archived redo logs, backs up the requested database files in separate sets, and performs the documented final archived-log step. The job can therefore generate several backup sets even though the administrator entered one command.

A configured control-file autobackup is placed in its own backup set. When the target uses an SPFILE, RMAN can include it with the control-file autobackup under the documented conditions. These files are essential to many disaster-recovery scenarios, but they do not remove the need to protect password files, TDE keystores, Oracle Net configuration, external files, and other deployment-specific assets.

RMAN has useful defaults, so administrators should not add output parameters without a measured reason. Several controls affect different layers of the backup:

• FILESPERSET limits the number of input files that RMAN places in each backup set.
• MAXSETSIZE limits a logical set and can cause RMAN to create additional sets.
• MAXPIECESIZE limits each physical piece. A set larger than that limit is written as multiple pieces.
• SECTION SIZE divides a large file into sections for a multisection backup.

Multiple configured or allocated channels normally create multiple backup sets in parallel. A multisection backup is the important special case. It allows several channels to process sections of one large file concurrently, and each section is stored in a separate backup piece.

BACKUP AS BACKUPSET
  SECTION SIZE 8G
  DATAFILE 7;

This example demonstrates syntax, not a recommended production section size. Choose section and piece limits from actual file sizes, channel counts, filesystem or media-manager limits, measured throughput, and recovery requirements. The Reference also prohibits combining SECTION SIZE with MAXPIECESIZE in the same operation.

Backup multiplexing occurs when one channel reads blocks from multiple input files and interleaves those blocks in the same backup piece. The effective multiplexing level is influenced by the input files assigned to the set and the channel's MAXOPENFILES setting. FILESPERSET limits the number of input files in the set.

Multiplexing can help keep a channel supplied with data when reads come from several files. It is not automatically a restore advantage. Excessive multiplexing can make restores less efficient because the blocks needed for one file are interleaved with blocks from others. Test it against the actual storage and recovery workload.

Do not confuse RMAN multiplexing with binary compression, multisection backup, multiple copies, or a media manager combining several channel streams on one sequential device. Oracle distinguishes backup-set multiplexing from media-manager multiplexing and recommends that media-manager multiplexing not be used for RMAN backups.

A full data-file backup and an incremental level 0 backup can contain the same data, but they have different roles. A full backup is not part of an incremental strategy and cannot be the parent of a subsequent level 1. A level 0 establishes the base for later level 1 backups.

Backup	Data represented	Relationship to level 1	Typical command
Full backup set	Allocated data-file blocks, subject to RMAN block-compression behavior.	Cannot be the incremental base.	BACKUP DATABASE;
Incremental level 0	Base containing the data blocks needed for the incremental strategy.	Serves as the parent for level 1.	BACKUP INCREMENTAL LEVEL 0 DATABASE;
Differential level 1	Blocks changed since the latest eligible level 0 or level 1.	Depends on a level 0 base.	BACKUP INCREMENTAL LEVEL 1 DATABASE;
Cumulative level 1	Blocks changed since the latest eligible level 0.	Depends on a level 0 base.	BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;

RMAN uses only incremental levels 0 and 1. Level 1 backups are created as backup sets. A level 0 can be a backup set or an image copy. Archived redo log backups do not use data-file incremental levels.

A full image copy includes every data block in its copied data file. A full or level 0 backup set can omit blocks under RMAN's null-block and unused-block compression rules. These forms of block compression are different from binary compression requested with AS COMPRESSED BACKUPSET.

A differential level 1 backup copies blocks changed since the most recent eligible incremental backup at level 0 or level 1. Differential is the default, so an ordinary level 1 command needs no DIFFERENTIAL keyword. A cumulative level 1 instead copies blocks changed since the most recent eligible level 0.

BACKUP INCREMENTAL LEVEL 0 DATABASE;
BACKUP INCREMENTAL LEVEL 1 DATABASE;
BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;

Assume a level 0 is made on Sunday. In a differential schedule, Monday contains changes since Sunday. Tuesday contains changes since Monday's level 1, and Wednesday contains changes since Tuesday's level 1. The daily backups are generally smaller because each one advances the reference point. Recovery through Wednesday can require Sunday and the applicable sequence of differential level 1 backups.

In a cumulative schedule, Monday contains changes since Sunday. Tuesday again begins with Sunday's level 0 and therefore repeats Monday's changes along with Tuesday's changes. Wednesday contains all changed blocks since Sunday. The backup normally grows as the week progresses, but recovery through the latest cumulative level 1 needs fewer incremental sets.

The diagram compares the incremental chain only. A database recovery can also require the correct control file, SPFILE, backup pieces, archived redo, encryption material, repository information, and destination access. A shorter incremental chain is not proof that the complete recovery will meet its recovery time objective.

Differential level 1 backups usually consume less time and space because each run captures changes since the latest incremental. More members of the chain may need to be located, read, and applied during recovery. Cumulative level 1 backups repeat earlier changes since the level 0, so later runs can consume more time and capacity. Recovery can apply the level 0 and the latest applicable cumulative backup rather than each earlier level 1.

The right schedule follows measured recovery objectives, change volume, backup windows, storage capacity, destination throughput, retention, and the frequency of level 0 backups. Avoid the old rule that every full backup belongs in a quiet period and every incremental belongs in a busy period. Backup impact depends on the environment, and a smaller backup is not automatically the faster recovery choice.

If RMAN is asked to make a level 1 without an eligible level 0 in the current or parent incarnation, its documented behavior can cause the operation to create level 0 content. This protects the chain from having no base, but administrators should still inspect the job output and repository records. A job name saying “level 1” is not sufficient evidence of the result.

A backup set's repository status and its retention-policy classification answer different questions. An AVAILABLE record indicates that RMAN expects the backup to be usable through its recorded device. It does not guarantee that every storage dependency, media credential, or encryption key will be available during a disaster.

EXPIRED means that a crosscheck could not find or access the backup through an allocated channel of the appropriate device type. The CROSSCHECK command changes repository status; it does not delete the physical piece. A backup can be marked expired because media is offline, an SBT integration is unavailable, or a piece was moved outside RMAN. Correct the underlying condition and crosscheck again before assuming the data is permanently lost.

OBSOLETE is different. It means that the configured retention policy considers the backup unnecessary for satisfying the current recovery window or redundancy goal. An obsolete backup can still be physically present and readable. Conversely, a recent available backup may still be insufficient for a particular recovery target if required redo, companion sets, or recovery credentials are missing.

Use REPORT OBSOLETE to evaluate the retention policy and LIST BACKUP to inspect recorded backup metadata. Coordinate any DELETE OBSOLETE operation with archived-log deletion rules, destination lifecycle controls, legal retention, replica policy, and the tested recovery design. Storage cleanup is part of recoverability, not a separate housekeeping decision.

Block change tracking can improve level 1 backup performance. When enabled, the database records changed-block information in a small binary file. RMAN can use it to avoid scanning every block in every data file when creating eligible incrementals greater than level 0. RMAN still checks the blocks that it reads and selects the required contents according to the incremental starting point.

Block change tracking does not change the difference between differential and cumulative backups. It does not remove the level 0, replace archived redo, validate backup media, or prove that recovery works. It is also different from backup optimization, which can skip files that already satisfy configured backup criteria.

Mechanism	What it controls	Common misunderstanding
Block compression	Omits blocks that RMAN does not need to store under documented rules.	It is not ordinary binary compression.
Binary compression	Compresses backup-set output when requested or configured.	It is not multiplexing.
Encryption	Protects backup-set contents using an approved RMAN encryption mode.	It does not remove keystore or password recovery requirements.
MAXPIECESIZE	Limits each physical backup piece.	It does not limit the entire logical set.
MAXSETSIZE	Limits a logical backup set.	It does not directly choose the piece count.
SECTION SIZE	Divides a large file for multisection processing.	It is not backup multiplexing.

Encryption is valuable only when its recovery material is protected and tested. An unreadable encrypted backup is not a successful security outcome. Likewise, aggressive binary compression can reduce storage and network use while increasing CPU demand. Evaluate features through repeatable backup and restore measurements rather than assuming that the smallest output is the best result.

RMAN performs physical checks while reading database blocks for backup, and backup pieces contain information that RMAN can use during validation. Those checks are useful but do not establish end-to-end recoverability. Use a verification ladder in which each operation answers a different question.

LIST BACKUP SUMMARY;
VALIDATE BACKUPSET 42;
RESTORE DATABASE VALIDATE;

• LIST BACKUP SUMMARY reports repository records. It does not read every piece.
• CROSSCHECK reconciles repository status with whether backup files are present and accessible through their configured device.
• VALIDATE BACKUPSET 42 reads the specified set and checks its blocks. Use an actual set key from the target environment.
• RESTORE DATABASE VALIDATE tests whether RMAN can select and read the backups needed for a database restore without writing restored data files.
• An isolated restore-and-recovery drill tests more of the complete procedure and remains the strongest operational evidence.

CHECK LOGICAL can add logical block checks to the physical checks performed by an applicable validation command. Validation still cannot prove that credentials will be available during a disaster, that a TDE keystore can be opened, that every network and media dependency will function, or that the database can be recovered within the approved RTO.

Oracle AI Database 26ai uses the multitenant architecture. RMAN can create backup sets for the supported whole-CDB, PDB, tablespace, data-file, control-file, SPFILE, and archived-log scopes allowed by the command and connection context. The logical set and physical piece definitions do not change when Cloud Control submits the job or when the output uses DISK or SBT.

A PDB backup is not complete CDB protection. The recovery design must also account for the CDB root, control file, SPFILE, archived redo, encryption material, and service-specific requirements. Confirm the protected scope in RMAN output and repository records rather than inferring it from a schedule or filename.

Backup sets give RMAN a flexible, Oracle-aware format for physical protection, but every strategy must be evaluated from recovery backward. The next lesson examines image copies, which preserve a different physical relationship to the source files and support different operational choices.

• Oracle AI Database Backup and Recovery User's Guide, 26ai
• Oracle AI Database Backup and Recovery Reference, 26ai