Lesson 9

This module introduced the physical backup choices available through Oracle Recovery Manager (RMAN) in Oracle AI Database 26ai. A reliable backup operation begins with more than a command. The DBA must identify the database scope, understand whether recovery will require redo, select a physical backup format, provide channels and destinations, preserve repository metadata, and verify that the result can satisfy the recovery objective.

Backup sets and image copies are the two principal RMAN physical backup formats. A backup set contains one or more backup pieces in an RMAN-specific format. An image copy is a bit-for-bit copy of one data file, control file, or archived redo log on disk. The older phrase image set can suggest that several files form one physical RMAN object, but RMAN records each image copy separately. A tag can label related copies without changing that structure.

The lessons also distinguished RMAN-created image copies from user-managed copies made with operating-system or storage tools. Both can be useful, but their creation procedures are not interchangeable. RMAN understands Oracle blocks and records its output automatically. An external tool copies bytes, so the DBA must establish file consistency, retain the required redo, and catalog each supported copy before RMAN can select it automatically.

After completing this module, you should be able to:

1. Distinguish online and offline backup conditions from consistent and inconsistent backup states.
2. Explain why an open RMAN backup requires archived redo and why RMAN does not require user-managed backup mode.
3. Compare backup sets, backup pieces, and image copies by structure, destination, storage use, and recovery behavior.
4. Explain how automatic and manual channels perform RMAN backup, restore, and recovery I/O.
5. Use the BACKUP command to select a backup format, scope, level, and tag.
6. Create and manage image copies of eligible database files on disk.
7. Use multiple DISK channels for file-level parallelism and SECTION SIZE for a large data file.
8. Create user-managed copies only with an appropriate consistency procedure and catalog them using the correct object type.
9. Relate repository records, crosschecks, validation, retention, and restore testing to a complete recovery strategy.

A backup format should be selected from the recovery requirement, not from familiarity with one RMAN command. The recovery time objective determines how quickly service must return. The recovery point objective determines how much recent work the organization can afford to lose. Those objectives influence the frequency of database and archived-log backups, the location and number of retained copies, the use of incremental backups, and the amount of recovery work that remains after a failure.

The protected scope also matters. In the multitenant architecture, a job may protect the complete container database (CDB), selected pluggable databases (PDBs), tablespaces, individual data files, the control file, or archived redo logs. A file-level backup can be valid without being sufficient for the intended recovery. The plan must identify every required component, including the server parameter file, control-file metadata, archived redo, Transparent Data Encryption keystore, and any credentials needed to reach protected storage.

RMAN makes physical backups through server-side channel sessions. The RMAN client directs the work, but data does not pass through the client. A DISK channel reads or writes disk-accessible storage such as a filesystem, an ASM disk group, or the Fast Recovery Area. An SBT channel communicates with a supported media-management or cloud-storage integration. Image copies are DISK objects; backup sets can be written to DISK or SBT.

An online backup is created while the selected database components remain open. An offline backup is created while the database or component is unavailable for ordinary use. These terms describe availability during the operation. They do not, by themselves, establish whether the backup is consistent.

A consistent whole-database backup represents one common checkpoint and normally follows a clean shutdown. An open whole-database backup is inconsistent because data files continue to change while channels read them. It remains recoverable when the database operates in ARCHIVELOG mode and the required archived redo is retained. Media recovery applies redo after the files are restored so that they reach a mutually consistent point.

RMAN does not require ALTER TABLESPACE ... BEGIN BACKUP when it backs up an open database. Its server sessions understand the Oracle block format, detect fractured blocks, and reread blocks when necessary. Backup mode belongs to documented user-managed workflows in which a generic operating-system or storage tool copies online read/write data files without RMAN's database-aware block handling.

A database in NOARCHIVELOG mode cannot support an ordinary open whole-database RMAN backup. It requires a consistent closed backup because archived redo is not available to reconcile changing files after restoration. Even in ARCHIVELOG mode, a usable online-backup policy must retain the logs required by its recovery window rather than assuming that a completed database backup is self-contained.

RMAN physical backup format review

Decision area	Backup set	Image copy
Physical structure	One or more RMAN-formatted backup pieces	One bit-for-bit disk file for each copied source file
Destination	DISK or SBT	DISK only
Storage use	Can omit blocks that do not need backup and can use RMAN binary compression	Normally occupies approximately the source file's full allocated size
Recovery path	RMAN reads backup pieces and reconstructs the selected files	RMAN can restore the copy or switch to a suitable data-file copy
Incremental role	Supports level 0 and level 1 incremental backups	Can be rolled forward by applying level 1 incremental backup sets
Common advantage	Storage and destination flexibility	Direct file form that can reduce restore preparation time

RMAN creates backup sets by default unless configuration or command syntax selects copies. A full backup and a backup set are not synonyms. Full describes the blocks selected from the object, while backup set describes the output format. Likewise, a level 0 incremental backup is similar to a full backup in the blocks it selects, but it can serve as the parent of later level 1 incremental backups.

An image copy cannot use backup-set multiplexing, backup-piece compression, or COPIES duplexing. Those are backup-set behaviors. Image copies can still participate in an incrementally updated strategy. RMAN creates level 1 incremental backup sets and applies them to an existing data-file copy with RECOVER COPY. The result is a full-sized disk copy advanced toward a more recent recovery point.

The direct form of an image copy does not eliminate recovery. A switched data-file copy may still need archived redo or incremental changes applied before the database can open consistently. Conversely, a compact backup set may be the better operational choice when capacity, transport, encryption, or SBT storage matters more than avoiding file reconstruction during restore.

The BACKUP command identifies what RMAN should protect and how the output should be created. Persistent CONFIGURE settings can supply automatic channels and a default disk backup type. A RUN block can allocate manual channels for one job. When manual channels are allocated for a device type, they replace the automatic channels of that type for the job.

The following commands illustrate the format distinction and use the required code-block structure for this site:

BACKUP AS BACKUPSET DATABASE TAG 'WEEKLY_BACKUPSET';
BACKUP AS COPY DATABASE TAG 'WEEKLY_IMAGE_COPY';

A tag is a reusable repository label. It can identify related output from a command and can be used by RMAN operations that support tag selection. A descriptive naming convention can communicate schedule, purpose, scope, or recovery tier. A tag does not create a physical container, make a copy valid, enforce retention, or prove that the required redo exists.

Channels determine concurrent I/O. One channel processes one backup set, copy, or eligible section at a time. Multiple channels can improve throughput when the source and destination paths have unused capacity. They can also compete with applications and with one another for CPU, memory, storage queues, and network bandwidth. The effective channel count is therefore a measured operating value, not a universal constant.

Routine jobs often benefit from automatic channels because the configuration is visible and reusable. Manual channels are useful when a single operation needs special destinations or settings. In both cases, confirm the actual job output. Configuring four channels does not guarantee that four useful units of work exist or that the storage system can sustain four concurrent streams.

BACKUP AS COPY is the current RMAN method for creating managed image copies. The standalone COPY command is deprecated. RMAN can create copies of eligible data files, control files, and archived redo logs, record them in the target control-file repository, and synchronize the metadata to an optional recovery catalog.

BACKUP AS COPY
  DATABASE
  TAG 'WEEKLY_IMAGE_COPY';

If a destination is not stated in the command, RMAN uses the applicable configured DISK destination and naming rules. The DBA must verify capacity before the job because each data-file copy includes the source file's complete physical block layout. The destination must also remain available to the recovery host, not merely to the host that created the backup.

There are two levels of image-copy parallelism. With multiple DISK channels, RMAN can assign different files to different channel sessions. If one very large data file leaves other channels idle, SECTION SIZE can divide that file into work sections. Several channels can then read and write its sections concurrently, but RMAN still produces one image copy for that source data file.

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

Section size and channel count must be tested against representative files and workloads. Many small files may already provide enough file-level work to keep channels active. A database dominated by one large file may benefit more from multisection copying. In either case, parallelism changes elapsed time and resource consumption, not the number of redundant copies.

An operating-system command, snapshot, or split-mirror tool can create a supported user-managed copy, but the external tool does not automatically coordinate Oracle checkpoints or repository records. The DBA must choose a consistency method that matches the state of each file. Typical methods include copying after a clean shutdown, taking an eligible tablespace offline normally, or placing an online read/write tablespace in backup mode for the duration of the external copy.

For an online user-managed tablespace copy, identify every current data file, confirm ARCHIVELOG mode, begin backup mode, copy all selected files, end backup mode promptly, and archive the current redo. Backup mode can increase redo generation, so it should not be left active longer than required. A storage snapshot must follow both Oracle's requirements and the vendor's documented application-consistency procedure. A crash-consistent snapshot is not automatically an Oracle-recoverable backup.

Control files and archived redo logs require object-specific treatment. Prefer an Oracle-created binary control-file backup over a raw copy of an active control file. Copy only completed archived redo log files, and never restore an old operating-system copy of an online redo log as if it were a backup.

After a supported external data-file copy is stable and disk-accessible, catalog it using its exact path:

CATALOG DATAFILECOPY '/backup/imgcopies/users01.dbf';
LIST COPY;
CROSSCHECK COPY;

CATALOG reads identifying header information and creates a repository record. It does not read every block, repair a partial copy, prove that backup mode was used correctly, or guarantee that recovery has all required redo. LIST displays recorded objects, while CROSSCHECK reconciles repository status with files RMAN can access. Neither replaces block validation or a controlled restore-and-recovery test.

RMAN-created image copies are preferable for routine protection when they satisfy the requirement. They provide database-aware block handling and immediate repository integration. User-managed copies remain appropriate for some storage technologies and operational constraints, but only as part of a documented and tested procedure.

The target control file always contains RMAN repository metadata. An optional recovery catalog can preserve longer history, centralize information for registered databases, and provide additional catalog capabilities. The catalog does not replace the target control file, and neither repository contains the backup data itself.

This distinction is important during a failure. Repository metadata can say that an image copy or backup piece exists even after an administrator, storage policy, or failed mount has made the file inaccessible. A file can also be present but corrupt. The operational lifecycle must therefore include inventory, capacity monitoring, crosschecks, retention processing, security controls, validation, and restore testing.

Evidence required beyond a successful backup command

Control	Question it answers
Job monitoring	Did the command complete, and which files, pieces, copies, channels, and destinations were involved?
LIST and reporting	What backup metadata does RMAN currently know?
CROSSCHECK	Are recorded objects accessible through their expected storage interfaces?
Validation	Can RMAN read the selected backup blocks and detect relevant corruption?
Restore and recovery test	Can the complete procedure meet the required recovery point and recovery time?

Retention must protect all dependencies of the recovery window. That includes database backups, archived redo, control-file or catalog information, encryption keys, credentials, and storage access. A deletion policy should be exercised through RMAN where appropriate so that repository metadata and physical storage remain aligned. External deletion can leave stale records and can silently break a recovery chain.

Security belongs inside the design. Image copies resemble live database files and require strict file ownership, permissions, access control, monitoring, replication, and secure disposal. Data protected by Transparent Data Encryption remains encrypted in copied data blocks, but recovery still depends on the associated keystore. RMAN encryption choices, storage encryption, and credential protection must be documented and tested for the selected backup format and destination.

1. Define the recovery point, recovery time, availability, and retention requirements.
2. Identify the CDB, PDB, tablespace, data-file, control-file, and archived-log scope.
3. Determine whether the operation is online or offline and whether recovery will require archived redo.
4. Select a backup set when compact RMAN storage, SBT, compression, or piece-based transport is important.
5. Select an image copy when disk capacity is available and direct file use or an incrementally updated strategy supports the objective.
6. Choose automatic or manual channels, then measure a safe degree of parallelism.
7. Assign descriptive tags and verify the actual destination, naming, and repository records.
8. Protect archived redo, metadata, keystores, and credentials for the entire recovery window.
9. Crosscheck and validate backups, then perform scheduled restore-and-recovery tests.
10. Revise the design when database growth, workload, storage, topology, or recovery objectives change.

No single command proves recoverability. A good design connects format, scope, state, channel behavior, repository information, retained redo, and tested procedures. That connection is the central lesson of this module.

Backup piece

A physical file produced as part of an RMAN backup set.

Backup set

A logical RMAN backup object containing one or more backup pieces in RMAN's backup-set format.

Channel

A database-server session that performs RMAN backup, restore, or recovery I/O for a specified device type.

Image copy

A bit-for-bit disk copy of one data file, control file, or archived redo log.

Incrementally updated image copy

A data-file copy advanced by applying later level 1 incremental backup sets.

Repository

RMAN metadata stored in the target control file and, optionally, synchronized to a recovery catalog.

Section

A range of blocks in one large data file that can be assigned as a unit of work during a multisection backup or copy.

Tag

A reusable, case-insensitive label stored with an RMAN backup or copy for identification and supported selection operations.

Use the quiz to review RMAN image copies, user-managed copies, cataloging, and file scope.

Image Copies - Quiz

Click the Quiz link below to review your understanding of image copies.
Image Copies - Quiz
In the next module, you will learn more about using backup sets.