Creating and Managing RMAN Image Copies

Understand the RMAN Architecture

The RMAN client accepts commands and directs backup, restore, and recovery jobs. The data does not flow through the client. Each allocated channel is a database-server session that performs the actual work for a particular device type. A DISK channel writes to disk storage such as the Fast Recovery Area (FRA), an Oracle Automatic Storage Management (ASM) disk group, or a filesystem. An SBT channel communicates through a native SBT library or media-management layer before reaching a supported cloud service, Recovery Appliance, or optional tape library.

Image copies are DISK outputs. An SBT channel can back up an existing image copy into backup-set media, but that SBT output is a backup set rather than another image copy. This distinction prevents the physical format from being confused with the device on which a later backup may reside.

Enterprise Manager Cloud Control and the OCI Console can provide optional management, scheduling, policy, and monitoring interfaces. They do not replace RMAN or perform the database-aware data transfer themselves. The RMAN client directs the operation, and its server-side channels read from or write to the target database and backup destinations.

The architecture applies whether the target CDB runs on-premises, in OCI, or in a multicloud environment. An SBT path may lead to Oracle Database Autonomous Recovery Service, OCI Object Storage, Recovery Appliance, another supported object-storage integration, or optional tape. Module 6, however, focuses on image copies written through DISK channels.

Compare Backup Sets and Image Copies

When RMAN executes BACKUP, its output is one or more backup sets or one or more image copies. RMAN creates backup sets by default. For a disk operation, AS BACKUPSET or AS COPY can select the required format explicitly.

An image copy is not an export, logical backup, or duplicated database. It preserves the physical contents of its source file. This direct form can be valuable when recovery time is important because RMAN may be able to switch to a suitable data-file copy instead of first reconstructing the file from a backup set. Recovery is still required when the copy must be advanced with archived redo or incremental backups.

It is also inaccurate to say that image copies cannot participate in an incremental strategy. The image copy itself is full-sized, but an incrementally updated backup strategy creates level 1 incremental backup sets and applies them with RECOVER COPY. This keeps the disk copy closer to the required recovery point and can reduce the work needed after a failure.

Relate Database State to Backup Consistency

An open database backup is commonly called an online or hot backup. RMAN can back up an open database in ARCHIVELOG mode because the archived redo required to make restored data files consistent is retained. RMAN server sessions understand Oracle block structure, detect fractured blocks, and reread blocks when necessary. An RMAN-created online backup does not require ALTER TABLESPACE ... BEGIN BACKUP.

A mounted or closed backup is commonly called an offline backup. If the database was shut down consistently, RMAN can create a consistent whole-database backup while it is mounted. A database operating in NOARCHIVELOG mode can be backed up by RMAN only when it is closed and in a consistent state. The database still has online redo logs; the relevant issue is whether the backup files are consistent and whether redo must be applied after restoration.

User-managed copies follow different rules. If an operating-system or storage tool copies an online data file, the administrator must follow the documented backup-mode and consistency procedure for the selected CDB, PDB, tablespace, or data file. The safeguards required for a user-managed copy must not be transferred mechanically to an RMAN-created image copy.

Keep Repository Metadata Separate from Backup Data

The target control file contains the authoritative RMAN repository for its database. It records information about database structure, backups, image copies, archived redo logs, and persistent RMAN configuration. When RMAN is connected to an optional recovery catalog, it also synchronizes metadata with the catalog. The catalog can preserve longer history, support centralized reporting across registered databases, and provide stored scripts and other catalog-dependent capabilities.

Repository metadata and backup data are related but different. A repository row says what RMAN knows about a copy. It does not prove that the file is still present, readable, complete, and sufficient for the required recovery. LIST reports recorded objects, CROSSCHECK reconciles their repository status with accessible storage, and validation or restore testing provides stronger evidence about readability and recoverability.

Create and Tag an Image Copy

Use BACKUP AS COPY to create RMAN-managed image copies. The standalone COPY command is deprecated. This introductory example uses a configured DISK destination and assigns one tag to the related output copies:

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

RMAN creates one image copy for each eligible database file. The DISK channel's server session reads the Oracle blocks, checks their structure, writes the copy, and records it in the repository. The tag is stored with each individual output copy. It helps identify related backups, but it does not turn the files into one physical “image set.”

Tags can help select backup sets or image copies in later RMAN operations where the command supports a tag. RMAN creates a default tag when one is not supplied, except for documented exceptions. Explicit operational tags are often easier to recognize, but they do not replace a retention policy, a storage inventory, validation, or restore testing.

An image copy can be created for a complete CDB or for eligible components such as PDBs, tablespaces, data files, control files, and archived redo logs. Each later lesson should state the exact scope and connection context rather than using “database backup” as an ambiguous label.

Use Channels and Parallelism Deliberately

RMAN can allocate channels automatically from persistent configuration or manually inside a RUN block. Configured automatic channels are usually clearer for routine work. A manually allocated channel supplies job-specific control and overrides the automatic channels for that job. Current syntax identifies DEVICE TYPE DISK or DEVICE TYPE SBT; a generic TAPE device type is not the current RMAN model.

Multiple DISK channels can copy different files concurrently. For a large data file, SECTION SIZE can divide the file into sections so that multiple channels create the copy in parallel. The output remains one image copy for each source data file.

CONFIGURE DEVICE TYPE DISK PARALLELISM 4;
BACKUP AS COPY
  SECTION SIZE 8G
  DATABASE
  TAG 'PARALLEL_IMAGE_COPY';

More channels do not guarantee a faster backup. Parallel work consumes CPU, memory, source-storage bandwidth, destination throughput, and, when remote storage is involved, network capacity. The useful channel count depends on measured bottlenecks and on restore requirements, not on a fixed formula. Capacity planning is especially important for image copies because each copy includes every block in its source file.

Catalog User-Managed Copies Carefully

Oracle 26ai can use supported image copies produced outside RMAN, including copies made with operating-system commands, storage snapshots, or third-party tools that leave accessible database files on disk. Oracle calls these user-managed backups. Their usefulness depends on whether the files were copied in a state that can be recovered correctly.

A safe high-level workflow is to prepare the selected database files, create the external copy, end backup mode or resume activity when the documented procedure requires it, and then use the appropriate CATALOG command to record the copy in the RMAN repository. After the copy is cataloged, RMAN can consider it for documented RESTORE or SWITCH operations.

Cataloging is not the same as validating. RMAN reads identifying information before recording a copy, but CATALOG does not read every block, prove that the copy was created correctly, or demonstrate that all required archived redo is available. Use repository maintenance, validation, and controlled restore-and-recovery tests to establish stronger recovery evidence.

RMAN-created image copies are generally preferable when they meet the requirement. Their server sessions understand Oracle file structure, perform block checks while copying, and record metadata immediately. User-managed methods remain useful for particular storage technologies or operational constraints, but they require careful coordination between database state, storage behavior, and repository maintenance.

Manage Image Copies as Recovery Assets

A successful BACKUP command is the beginning of protection, not the end. An operational process must monitor destination capacity, reconcile repository records, enforce retention, protect credentials and encryption material, validate readable backups, and test the complete restore-and-recovery path. Encryption is configurable; the presence of native RMAN encryption support does not mean that every backup is automatically encrypted.

In the next lesson, you will distinguish online and offline backup conditions and determine when RMAN can create a consistent or recoverable backup of a target CDB or selected PDBs.