RMAN Backup Sets and Image Copies in Oracle 26ai

Every Oracle Recovery Manager (RMAN) BACKUP specification produces one or more backup sets or one or more image copies. These remain the two principal physical backup output formats in Oracle AI Database 26ai. A backup set is an RMAN-specific logical container made up of backup pieces. An image copy is a byte-for-byte copy of one data file, control file, or archived redo log and exists only on disk.

The format is only one part of a backup decision. Device type, backup level, and database state describe different characteristics of the same operation. Keeping them separate prevents statements such as “an image copy is an offline backup” or “a backup set is an incremental backup.” Either format can be created under supported open or mounted conditions, and a backup set can be full or incremental.

Neither output format is a complete backup strategy. A dependable strategy also defines the target CDB or PDB scope, schedule, database state, retention policy, destinations, encryption requirements, archived-redo handling, monitoring, validation, and tested recovery procedures.

Backup Sets and Backup Pieces

A backup set is the smallest logical unit of an RMAN backup. It contains backed-up Oracle blocks and related RMAN metadata from one or more eligible input files. A backup set consists of one or more backup pieces. Each backup piece is a physical binary file in an RMAN-specific format. Only RMAN creates and interprets backup sets and their pieces.

• An RMAN backup job can create one or more backup sets.
• Each backup set contains one or more backup pieces.
• Each piece contains the Oracle blocks and RMAN metadata assigned to it by the channel.

A backup set can protect data files belonging to a complete CDB, selected PDBs, tablespaces, or individual data files. RMAN can also create backup sets for archived redo logs, the control file, and the server parameter file. A single command can create several sets and pieces, depending on the protected objects, available channels, sectioning, piece-size limits, and other configuration.

The presence of internal metadata does not mean that every backup set automatically contains everything needed for every recovery. The overall procedure must protect the required data files, control-file or recovery-catalog information, server parameter file, archived redo, encryption wallets or keys, and any other assets required by the recovery objective.

Backup-Set Storage Efficiency

Data-file backup sets are typically smaller than image copies because RMAN can omit blocks that do not need to be stored. This behavior is called block compression. Null block compression omits blocks that have never contained data from full and level 0 backup sets. Unused block compression can omit blocks that are not currently allocated to database objects when its documented prerequisites are satisfied.

Block compression is not the same as optional binary compression. Block compression avoids writing eligible blocks. Binary compression applies a compression algorithm to the backup-set contents and is requested with AS COMPRESSED BACKUPSET or a persistent RMAN configuration.

BACKUP AS COMPRESSED BACKUPSET
  DATABASE PLUS ARCHIVELOG;

Binary compression can reduce storage consumption and network traffic, but it also consumes CPU during backup and restore. The reduction depends on the data, backup level, compression settings, and destination. Backup sets are not compressed automatically merely because they use the RMAN format. The default format for a DISK backup is an uncompressed backup set.

Multiplexing and Multisection Backups

RMAN can read blocks from multiple input files at the same time and place them in the same backup set. Oracle calls this backup multiplexing. A backup piece can therefore contain interleaved blocks from more than one source data file. Image copies are never multiplexed because each output copy corresponds to one source file.

A multisection backup solves a different problem. RMAN divides one large data file into sections so multiple channels can process it in parallel. Supported multisection operations can produce backup sets or image copies. With a multisection image-copy operation, channels write different sections concurrently, but the completed result remains one image copy for each source data file.

Multiplexing combines input from multiple files in a backup set. Multisection processing divides one file for parallel work. Channel count, FILESPERSET, MAXOPENFILES, section size, and storage throughput affect performance, but those tuning choices belong to the channel and performance portions of the backup plan.

Image Copies

An image copy is a byte-for-byte copy of one data file, control file, or archived redo log. It is not enclosed in an RMAN-specific container. A correctly created image copy is structurally equivalent to copying that Oracle file with an operating-system utility, although RMAN-created copies provide important database-aware safeguards and immediate repository registration.

Use BACKUP AS COPY to create RMAN-managed image copies:

BACKUP AS COPY
  DEVICE TYPE DISK
  DATABASE
  TAG 'WEEKLY_IMAGE_COPY';

The channel's database-server session reads and checks Oracle blocks, creates a separate copy for each eligible source file, and records each copy in the target control-file repository and optional recovery catalog. Because every block in a data-file image copy is retained, the copy normally uses storage comparable to the source file.

Image copies exist only on DISK, including the Fast Recovery Area, an Oracle Automatic Storage Management disk group, or a filesystem. RMAN cannot write an image copy directly through an SBT channel to cloud object storage, Recovery Appliance, or tape. RMAN can back up an existing disk image copy through SBT, but the new SBT output is a backup set.

An approved external tool can also create a user-managed image copy. The database or selected files must be placed in the correct state, including the backup-mode procedure described in Lesson 2 when required. The RMAN CATALOG command can inspect the copy's identifying information and add repository metadata. Cataloging does not read every block, prove that backup mode was coordinated correctly, or demonstrate that the copy and required archived redo can complete a recovery.

Restore from a Copy or Switch to It

RMAN restores a backup set by reading the required backup pieces and reconstructing the selected file at its original or new destination. For an image copy, RESTORE can copy the selected disk file back to the required destination. These are both restore operations.

A data-file image copy provides another option when it is already accessible at a suitable location. A documented SWITCH ... TO COPY operation can update the control file so the database begins using that copy in place. Switching can reduce or avoid the file-copy portion of the restore because the replacement file already exists.

Switching does not guarantee that the data file is current and does not eliminate media recovery. RMAN may still need to apply incremental backups or archived redo to advance the copy to the required system change number (SCN). Total recovery time depends on the copy's age and location, the amount of redo or incremental data, destination performance, and the failure scenario.

Full and Incremental 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 does not establish a base for future level 1 incremental backups. A level 0 backup does. This distinction matters even when the two outputs are similar in size.

A differential level 1 backup, which is the default level 1 type, includes blocks changed since the most recent eligible level 0 or level 1 incremental backup. A cumulative level 1 includes blocks changed since the most recent eligible level 0 backup. A cumulative backup is not based on the most recent ordinary full backup because a full backup does not participate as the parent of a level 1 incremental strategy.

Incrementally Updated Image Copies

Image copies can participate in an incremental strategy even though RMAN stores level 1 output in backup sets. The strategy begins with level 0 data-file image copies. RMAN periodically creates level 1 backup sets containing changed blocks and applies those changes to the copies with RECOVER COPY. The rolled-forward copies then require less archived redo if they are used during recovery.

RECOVER COPY OF DATABASE
  WITH TAG 'DAILY_IMAGE_COPY';

BACKUP INCREMENTAL LEVEL 1
  FOR RECOVER OF COPY
  WITH TAG 'DAILY_IMAGE_COPY'
  DATABASE;

The shared tag identifies the copies and level 1 backups that belong to the strategy. When no eligible tagged level 0 copy exists, the documented FOR RECOVER OF COPY behavior can create the required level 0 image copies. On later executions, RMAN applies available prior level 1 backup sets to the copies and creates the next level 1 backup set.

The result is called an incrementally updated backup. The image copy remains a full-sized disk file, while the daily level 1 outputs remain backup sets. A production implementation must also coordinate schedule, tags, retention, archived redo, destination capacity, and restore testing.

Configure the Default Backup Format

RMAN uses an uncompressed backup set as the default format for DISK. The persistent DISK configuration can be changed to image copies or changed back to backup sets. Compression can be configured independently for backup-set output:

CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY;
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO BACKUPSET;

CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET;
CONFIGURE DEVICE TYPE SBT BACKUP TYPE TO COMPRESSED BACKUPSET;

The CONFIGURE DEVICE TYPE setting is stored in the target database's RMAN repository and persists until it is changed or cleared. SHOW ALL displays the current RMAN configuration. A recovery catalog can preserve additional history and capabilities, but it is not required merely to store these ordinary target-database configuration settings.

An individual command can override the applicable default with AS COPY, AS BACKUPSET, or AS COMPRESSED BACKUPSET. DISK supports backup sets and image copies. SBT supports backup sets only, so it cannot be configured to create image copies. Oracle output may display SBT_TAPE, but SBT is the device type used in current command examples.

Compare the Formats

Neither format is universally better. A recovery design can use recent image copies on disk for rapid switching and backup sets for efficient retention, network transfer, cloud protection, Recovery Appliance, or optional tape. Format selection must follow the recovery point objective, recovery time objective, destination constraints, capacity, and measured restore performance.

Oracle 26ai Format Enhancements

Oracle 26ai adds capabilities around the two formats without introducing a third ordinary RMAN backup format. Native SBT libraries included with the target database installation can integrate RMAN with OCI, Recovery Appliance, Amazon S3, and Azure Blob Storage. These SBT paths receive backup sets rather than image copies.

Oracle 26ai also extends BACKUP BACKUPSET so an existing backup set can be backed up from tape to tape or from tape to disk using the documented input and output channel configuration. The feature moves or reprotects existing backup-set data; it does not change the underlying format model.

Apply the Format to a CDB or PDB Scope

When connected to the CDB root, BACKUP DATABASE protects the complete target CDB according to the documented eligibility rules, and BACKUP PLUGGABLE DATABASE can protect named PDBs. When connected directly to a PDB with the required administrative privilege, BACKUP DATABASE applies to that PDB.

Connection context does not change the two output formats, but it changes the protected scope. Archived-redo operations require the appropriate root connection and are not automatically included in every PDB backup. A complete recovery design must also protect required CDB root metadata, the control file or recovery catalog, archived redo, and other container-specific assets. Use a dedicated administrative identity granted SYSBACKUP where RMAN target authentication requires administrative access.

Validate the Format Decision

A successful BACKUP command proves that RMAN created recorded output, but it does not prove that the intended recovery objective can be met. LIST reports repository records, CROSSCHECK reconciles those records with accessible storage, and validation checks file or backup readability. These operations have different purposes and do not replace a controlled restore-and-recovery test.

Test the path that would actually be used after a failure. For a backup set, measure reconstruction and recovery from the required pieces. For an image copy, test the documented restore or switch workflow and apply the required incremental backups and archived redo. Include destination access, credentials, encryption material, control-file recovery, CDB or PDB scope, and application validation in the exercise.

RMAN Backup Formats Quiz

Use the quiz to review the differences between backup sets and image copies.

RMAN Backup Formats Quiz

In the next lesson, you will learn how RMAN channels create server sessions that read database files and write backup pieces or image copies to DISK and SBT destinations.