Oracle RMAN Image Copies

Oracle Recovery Manager, or RMAN, supports two principal physical backup formats: backup sets and image copies. Lesson 6 explained the RMAN-specific backup-set format. An image copy is different. It is an exact copy of one data file, archived redo log, or control file and has the same physical format as its source file.

Image copies remain fully supported in Oracle AI Database 26ai. RMAN can create them, inventory them in its repository, use them as restore sources, switch the database to eligible data-file copies, and roll level 0 data-file copies forward with level 1 incremental backup sets. These properties make image copies useful when recovery time is more important than minimizing disk capacity.

An image copy is not one file containing an entire database. For example, BACKUP AS COPY DATABASE produces a separate image copy for each selected data file. An ordinary copy is not multiplexed, so it does not interleave blocks from several source files. A full data-file image copy also contains every block in the source file, including blocks that have never been used.

Neither format is universally better. A backup set usually uses less capacity and supports more output options. An image copy preserves the original file structure and can sometimes be put into service without first copying it back to a data-file destination.

Characteristic	Image copy	Backup set
Format	File-for-file copy with the source file's physical structure.	RMAN-specific binary format containing one or more backup pieces.
Output unit	One ordinary copy for one source file.	One logical set that can contain data from several eligible input files.
Destination	Disk only.	DISK or SBT.
Multiplexing	Not used for ordinary image copies.	Possible for eligible data-file backup sets.
RMAN binary compression	Not available because the copy retains the source file format.	Available with compressed backup sets.
Direct data-file use	An eligible copy can become current through SWITCH ... TO COPY.	The data file must be restored from its backup pieces.
Incremental role	A level 0 data-file copy can be rolled forward.	Level 0 and level 1 backups can be stored as backup sets.

Image copies can exist on server-accessible filesystem storage, an Oracle Automatic Storage Management disk group, or in the Fast Recovery Area, depending on configuration. They cannot be written directly to tape or another SBT destination. If offsite or media-manager protection is required, RMAN can use backup sets as another layer of the strategy.

The BACKUP AS COPY command tells RMAN to create image-copy output. A target-database server session reads the source file, performs the applicable block checks, writes the copy to disk, and records its metadata in the target control file. If a recovery catalog is in use, RMAN can also maintain the synchronized metadata there.

BACKUP AS COPY DATABASE;
BACKUP AS COPY DATAFILE 5;
BACKUP AS COPY CURRENT CONTROLFILE;
BACKUP AS COPY ARCHIVELOG ALL;

The first command creates copies of the selected database data files. The second limits the work to data file 5. The third creates a control-file copy, which is different from a control-file autobackup. A control-file autobackup is stored in backup-set format. The fourth command creates separate copies of the selected archived redo logs.

RMAN creates backup sets by default unless the command or persistent configuration selects copies. An administrator can configure image copies as the default for future disk backups, but this is a lasting behavior change and should be made deliberately:

CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY;
SHOW DEVICE TYPE;
LIST COPY OF DATABASE;
LIST COPY OF CONTROLFILE;

Using AS COPY explicitly often makes teaching and runbooks clearer because the output format is visible in the command. The destination is also a server-side concern. A path supplied with FORMAT must be accessible to the target-database server session, not merely to the computer where the RMAN client was started.

LIST COPY displays repository records. It answers questions about registered copies, their keys, tags, status, completion times, and file names. It does not read every copied block, confirm that a file is still accessible, or prove that a complete recovery will succeed.

Repository status and retention status answer different questions. A copy with status AVAILABLE is recorded as usable, but that status does not prove that every block is readable. After CROSSCHECK COPY, a disk copy that RMAN cannot find is marked EXPIRED. Expired means that the repository record and the observed storage state disagree; it does not mean that the retention period elapsed.

A copy becomes OBSOLETE when RMAN determines that it is no longer needed under the configured retention policy. Obsolete is not the same as expired, corrupt, or automatically deleted. Review the recovery window or redundancy policy and confirm that newer backups satisfy the intended recovery range before issuing a deletion command.

Copies in the Fast Recovery Area participate in Oracle-managed space usage. When space pressure occurs, files that Oracle considers eligible for deletion can be removed to make room. The Fast Recovery Area improves management, but it is not a separate failure domain when it shares storage, credentials, or administrative control with the database it protects.

Tags and meaningful repository reports help operators identify which copies belong to an incrementally updated strategy, a migration task, or a specific recovery plan. Document the destination, responsible job, retention rule, encryption dependencies, and expected switch procedure. Periodically reconcile repository records with actual storage and investigate unexpected EXPIRED or missing files before they become a recovery incident.

When RMAN restores from an image copy, it normally copies the file to its original location or another configured restore destination. RMAN then applies the incremental backups and archived redo needed for the recovery target. In this workflow, the image copy remains a backup source.

A switch uses the copy differently. If a suitable copy already exists on accessible disk storage, SWITCH DATAFILE ... TO COPY changes the control file so that the latest eligible copy becomes the current data file. RMAN avoids the time required to copy that data file back to another location. It still must recover the copy to the required point.

The following abbreviated sequence reflects Oracle's documented open-database scenario for one unavailable data file. It assumes that an eligible copy exists, the required redo is available, and the affected data file can be taken offline:

SQL 'ALTER DATABASE DATAFILE 5 OFFLINE';
SWITCH DATAFILE 5 TO COPY;
RECOVER DATAFILE 5;
SQL 'ALTER DATABASE DATAFILE 5 ONLINE';

The operator must connect in the correct CDB or PDB context with SYSBACKUP or SYSDBA, verify the database state, and confirm that recovery completes before bringing the file online. Required incremental backups and archived redo logs must be available.

The switch is more than a status update. It changes the active data-file path recorded in the control file. The storage location that previously held a backup copy now supports an active production file and must satisfy production requirements for availability, capacity, protection, and performance. A copy kept on storage that is suitable only for backup retention should not be switched into service without addressing that change in role.

For a database-wide loss, RMAN also supports SWITCH DATABASE TO COPY while the database is mounted and eligible copies exist. When connected to a CDB root, a PDB operation uses SWITCH PLUGGABLE DATABASE TO COPY. When connected directly to the PDB, the documented form is SWITCH DATABASE TO COPY. These commands belong in a tested recovery runbook, not in routine backup maintenance.

RMAN can use copies created outside RMAN, including files produced by documented operating-system, storage-mirror, or snapshot procedures. Such a file is called a user-managed image copy. The concept remains current, but an arbitrary filesystem copy of an active data file is not automatically a valid backup.

A user-managed procedure must produce a recoverable Oracle file. Depending on database state and storage technology, that can require a consistent shutdown, the documented backup-mode procedure, or a coordinated storage snapshot. The resulting file must remain on storage that the target database server can access.

After a valid copy exists, the administrator can add its metadata to the RMAN repository:

CATALOG DATAFILECOPY '/backup/prod/users01.dbf' LEVEL 0;
LIST COPY OF DATAFILE '/backup/prod/users01.dbf';

The path is only an example. The LEVEL 0 clause records the copy as a potential base for an incremental strategy. It does not alter the file contents or convert an unsafe copy into a correct one.

Oracle identifies two important limits. CATALOG does not read every block to determine whether the copy is free of corruption, and it does not guarantee that the copy was made correctly in backup mode. After cataloging, RMAN can consider the file for restore or switch operations, but the file still needs separate validation and recovery testing.

If a user-managed copy is deleted or moved outside RMAN, reconcile the repository. A stale record can make an inventory appear healthier than the available recovery media. CROSSCHECK and the appropriate CHANGE ... UNCATALOG or maintenance command must be used according to the intended lifecycle.

An incrementally updated backup keeps a level 0 data-file copy on disk and periodically applies level 1 differential backup sets to it. The result is a copy that represents a more recent recovery point without repeatedly creating a new full image copy. Oracle also calls this an incremental-forever strategy.

1. A level 0 image copy establishes the base.
2. RMAN creates a level 1 differential backup set containing changed blocks.
3. RECOVER COPY OF applies the available level 1 backup to the tagged copy.
4. The updated copy requires less remaining redo to reach a later recovery target.
5. RMAN creates the next level 1 backup for the following update cycle.

RUN
{
  RECOVER COPY OF DATABASE
    WITH TAG 'incr_update';
  BACKUP
    INCREMENTAL LEVEL 1
    FOR RECOVER OF COPY WITH TAG 'incr_update'
    DATABASE;
}

The command order matters. On the first execution, no level 1 backup exists to apply. If no eligible level 0 copy has the tag, the BACKUP ... FOR RECOVER OF COPY command creates the required level 0 copies. The next execution creates the first level 1 backup. On later executions, RMAN first applies the available level 1 to the copies and then creates a new level 1 for the next cycle.

The level 0 base is an image copy, but each level 1 incremental is a backup set. Oracle does not create level 1 image copies. The shared tag associates the level 0 copies and the applicable incremental backups, so the same tag must be used consistently.

Rolling a copy forward does not switch the running database to it. The operation updates the backup copy on disk. During a later recovery, RMAN may still need archived redo to reach the requested time or system change number. The strategy also depends on control-file or catalog metadata, an SPFILE, control-file protection, encryption material, destination access, retention, and enough disk capacity.

RMAN performs physical checks while reading database blocks for a backup. Physical corruption can include an invalid checksum, an all-zero block, or a mismatch between a block header and footer. Logical corruption describes internally inconsistent block contents, such as a damaged row piece or index entry. Logical checks are not enabled by default; CHECK LOGICAL adds them where the command supports that option.

Use several kinds of evidence because each operation answers a different question:

LIST COPY OF DATABASE;
CROSSCHECK COPY;
VALIDATE COPY OF DATABASE;
RESTORE DATABASE VALIDATE;

Operation	What it establishes	What it does not establish
LIST COPY	Displays registered copy metadata.	Does not read the physical copy.
CROSSCHECK COPY	Reconciles repository status with whether RMAN can find the copy.	Does not validate every block or perform recovery.
VALIDATE COPY OF DATABASE	Reads and checks the selected database copies.	Does not prove that every other recovery dependency exists.
RESTORE DATABASE VALIDATE	Tests backup selection and readability without writing restored data files.	Does not apply redo and open the recovered database.
Isolated recovery drill	Tests more of the complete restore, recovery, and verification procedure.	Does not excuse monitoring, retention, or change control.

V$COPY_CORRUPTION can report corrupt block ranges recorded for data-file copies. V$BACKUP_CORRUPTION applies to backup sets, not image copies. An empty corruption view is not proof of recoverability because the necessary files may not have been read recently and other required artifacts can still be missing.

Not every possible failure can be detected by one command. A successful copy, crosscheck, or validation does not replace a scheduled recovery drill in an isolated environment. Recovery testing should verify the target time, the expected database state, application access, and the operational steps required to return service safely.

Oracle AI Database 26ai uses the multitenant architecture. A CDB-wide image-copy job is performed from the root by an appropriately privileged common user. RMAN also supports copy operations at PDB, tablespace, data-file, control-file, and archived-log scopes when the connection and command allow that scope.

A PDB data-file copy is not complete CDB protection. A recovery plan must also account for the CDB root, control file, SPFILE, archived redo, TDE keystore or other encryption material, network configuration, and repository metadata. Prefer SYSBACKUP when it provides the authority needed for the operation, rather than granting an account unrelated broad privileges.

Requirement	Design implication
Reduce copy-back time after a data-file loss	Keep an eligible copy on storage that can safely become an active data-file location.
Maintain a recent disk copy	Use a tagged level 0 image copy with level 1 backup sets in an incrementally updated strategy.
Write directly to tape or another SBT destination	Use backup sets because image copies exist only on disk.
Reduce capacity through RMAN binary compression	Use compressed backup sets rather than image copies.
Protect against loss of the primary storage system	Place another tested backup copy in a separate failure domain.
Prove the recovery plan	Validate the media and complete isolated restore-and-recovery drills.

A layered design can use both formats. Recent image copies may support rapid disk-based recovery, while backup sets provide longer retention, compression, media-manager integration, or offsite protection. The correct design follows the recovery point objective, recovery time objective, database size, change rate, backup window, storage capacity, and tested failure scenarios.

Lesson 8 introduces the optional RMAN recovery catalog. Whether or not a catalog is used, the target control file remains an RMAN repository. A catalog can extend metadata history and provide other management features, but it does not contain the image-copy data and cannot replace access to the actual backup files.