Creating RMAN Image Copies in Oracle 26ai

Yes. Oracle AI Database 26ai Recovery Manager (RMAN) can create image-copy backups of data files, control files, and archived redo logs. Use the BACKUP AS COPY command to create the copies on disk-accessible storage and record them in the RMAN repository.

An image copy is an exact, byte-for-byte copy of one source file. It is not packaged in an RMAN backup set or backup piece. For example, BACKUP AS COPY DATABASE creates a separate image copy for each selected data file rather than one file that contains the entire database. This one-to-one relationship is central to understanding how image copies differ from backup sets.

RMAN-created image copies combine an operating-system-accessible file layout with RMAN management. A database server session reads the source file, checks database blocks while copying them, writes the destination file, and records the copy in the target database control file. If a recovery catalog is used, the catalog can also retain the repository metadata. RMAN can then list, crosscheck, restore from, recover, and switch to appropriate copies.

The RMAN BACKUP command produces either backup sets or image copies. Backup sets are the default output unless an RMAN configuration or explicit command clause selects another supported output form. Both forms can protect database files, but their storage structures and recovery uses differ.

RMAN image copies compared with backup sets

Characteristic	Image copy	Backup set
RMAN syntax	BACKUP AS COPY ...	BACKUP AS BACKUPSET ...
Output structure	One destination file for each copied source file	One or more RMAN-formatted backup pieces
Destination	Disk-accessible storage	Disk or a supported SBT destination
File layout	Preserves the source file's block layout	Can omit blocks that do not need to be backed up
Recovery use	An accessible data-file copy can be selected with SWITCH	The required data must be restored from the backup pieces
Incremental-update role	A level 0 data-file copy can be rolled forward	Level 1 backup sets can supply the changed blocks

Image copies are never multiplexed. One copy cannot intermix blocks from several source files in the manner supported by a backup set. Image copies can also require more disk space and take longer to write than backup sets that benefit from unused-block or null-block compression. Their advantage is that the resulting files retain the physical form of the copied database files.

The nonproprietary layout does not make an image copy unmanaged, automatically recoverable, or universally portable. RMAN repository records, required redo, compatible storage, and a tested recovery procedure remain essential.

The current RMAN command for creating an image copy is BACKUP AS COPY. The standalone COPY syntax used in older course material should not be used for this lesson. The following commands select the database, a tablespace, or one data file:

BACKUP AS COPY DATABASE;
BACKUP AS COPY TABLESPACE users;
BACKUP AS COPY DATAFILE 4;

BACKUP AS COPY DATABASE creates image copies of the data files in the current connection scope. When RMAN is connected to the CDB root with the required administrative privilege, the database scope is the target CDB. When RMAN is connected directly to a PDB, supported database operations apply within that PDB's scope. Administrative RMAN work commonly uses the SYSBACKUP privilege.

The tablespace example selects all data files belonging to the users tablespace. The data-file example selects file number 4. These commands do not require a manually allocated channel when a suitable automatic disk channel is available. Manual disk channels remain useful when a job requires channel-specific settings, but channel allocation is not a prerequisite for every image-copy command.

A database image-copy command does not automatically mean that all archived redo logs are included. If the recovery plan requires archived redo logs, specify PLUS ARCHIVELOG where appropriate or run a separate archived-log backup. This distinction matters because an online data-file copy normally requires redo before it can be opened as part of a recovered database.

Image copies exist only on disk-accessible storage. The storage can be a conventional file system, Oracle Automatic Storage Management (ASM), or another disk destination that the database host can access. An SBT channel can create backup sets, but it cannot directly create an RMAN image copy.

Use the FORMAT clause when the command must name a particular destination file. This example uses an illustrative file-system path and assigns a descriptive tag:

BACKUP AS COPY DATAFILE 1
  FORMAT '/backup/df1_copy.dbf'
  TAG 'DF1_COPY';

The destination directory must already exist, be writable by the Oracle database process, and have enough capacity for the complete copied file. The DBA must also avoid names that conflict with current database files or required backup copies. A production path should reflect the site's storage design rather than copying this example unchanged.

If no command-level FORMAT is supplied, RMAN can obtain the output location and naming behavior from channel configuration, database configuration, the fast recovery area, or Oracle Managed Files rules. With ASM or Oracle Managed Files, allow Oracle to generate file names when the storage configuration requires it. RMAN substitution variables such as %U help produce unique names when a format string is appropriate.

The AS COPY output form is not limited to data files. RMAN can also create image copies of the current control file and archived redo logs:

BACKUP AS COPY CURRENT CONTROLFILE
  FORMAT '/backup/control01.ctl';

BACKUP AS COPY ARCHIVELOG ALL
  FORMAT '/backup/arch_%U.arc';

The first command creates a copy of the current control file. The second command creates an individual image copy for every archived redo log selected by ARCHIVELOG ALL. In the example, %U supplies an RMAN-generated value that helps make each destination name unique.

Archived redo belongs to the CDB's redo stream. In a multitenant database, archived-log backup operations are normally performed while connected to the CDB root rather than treating each PDB as though it had an independent archived redo stream. The backup plan must retain enough archived and online redo to recover the selected data-file copies to the required point.

A DBA can configure image copies as the default output type for disk backups. The configuration is persistent, so it should be changed only when image copies are intended as the routine disk-backup form:

CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY;
SHOW ALL;

SHOW ALL displays the current RMAN configuration and allows the DBA to verify the setting. After this configuration, a supported disk backup can create copies without repeating AS COPY. An explicit AS BACKUPSET clause can select backup-set output for an individual supported command.

For training and one-time operations, explicit BACKUP AS COPY syntax is usually clearer because it communicates the intended output form without changing persistent production configuration. Configuration changes should be reviewed with the broader retention, capacity, performance, and recovery strategy.

As introduced in Lesson 5, a tag is a reusable, case-insensitive repository label. A command-level tag applies to each image copy produced by the command:

BACKUP AS COPY DATABASE TAG 'WEEKLY_COPY';

The tag helps an administrator recognize and select related copies. It does not change the files being copied, their destination, their retention status, or their recoverability. Several backup jobs can reuse the same tag, so a tag is not a unique key. Selection can therefore match multiple repository records.

Use short, documented tag names that describe the copy's scope or purpose. For portable course examples, use letters, digits, and underscores and keep the value within the RMAN limit of 30 bytes. A name such as WEEKLY_COPY is more useful during an incident than an undocumented or ambiguous label.

Creating a copy is only one part of the workflow. The DBA should review the RMAN job result and inspect the corresponding repository records. The following commands list copies and check whether RMAN can still locate them:

LIST COPY;
LIST COPY OF DATAFILE 1;
CROSSCHECK COPY;

LIST COPY reports image-copy records known to the RMAN repository. LIST COPY OF DATAFILE 1 narrows the report to copies of data file 1. The output can be used to review information such as the copy key, file identity, status, completion time, tag, and physical name.

CROSSCHECK COPY compares repository records with the files that the allocated or configured channels can access. RMAN updates a record's status when the file is unavailable or available again under the applicable rules. Crosschecking does not read every database block, and an AVAILABLE record is not proof that a complete recovery will succeed.

A dependable backup process also monitors job completion, preserves the required archived redo, validates backups according to policy, and tests restore and recovery procedures. These checks address different risks and should not be replaced by a tag or a successful LIST command.

Restoring from an image copy and switching to an image copy are distinct operations. A normal RESTORE can copy an image copy to the requested or original data-file location. RMAN then applies the recovery steps required by the backup's checkpoint and the requested recovery target.

If a valid data-file copy is already accessible in a suitable location, an explicit SWITCH ... TO COPY command can update the control file so that Oracle Database treats that copy as the current data file. The following sequence illustrates a whole-database switch and recovery:

SWITCH DATABASE TO COPY;
RECOVER DATABASE;

SWITCH DATABASE TO COPY selects the latest available data-file copies according to RMAN's rules. It does not copy their contents back to the original locations. RECOVER DATABASE then applies the required incremental backups and redo to bring the selected files forward.

A real recovery procedure requires the correct database state, file scope, copy availability, privileges, and recovery target. Switching can avoid the physical copy-back portion of a restore, but it does not guarantee shorter total downtime. Storage performance, the age of the copy, the volume of redo, and the failure scenario determine the actual recovery time.

For these reasons, SWITCH DATABASE TO COPY should be part of a documented and tested recovery plan. The legacy claim that Oracle performs an implicit switch whenever an image copy is restored is incorrect.

An incrementally updated backup strategy combines the direct usability of a data-file image copy with the efficiency of level 1 incremental backup sets. A commonly used paired-command pattern is:

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

On the first applicable run, no matching level 0 copy exists for the strategy. The backup command therefore creates the required level 0 image copy. On later runs, the backup command creates level 1 incremental backup sets containing blocks changed since the applicable incremental parent.

The next execution of RECOVER COPY applies available incremental changes to the matching image copies and rolls them forward. The WITH TAG value associates both commands with the intended strategy. It has a more specialized role than an ordinary output TAG.

The level 1 backup is not itself an image copy in this strategy. The level 0 base remains the data-file image copy, while level 1 backup sets supply changed blocks used to update it. When the updated copy is selected during recovery, Oracle Database can still require archived or online redo after the copy's checkpoint.

This strategy can shorten the restore phase because RMAN maintains a relatively current copy on disk. It also consumes disk capacity and requires disciplined scheduling, retention, monitoring, and redo protection. A recovery test should confirm that the rolling update cycle produces the recovery readiness expected by the organization.

Operating-system commands, storage snapshots, and third-party tools can create files that may qualify as user-managed image copies. They do not automatically receive the safeguards and repository integration of an RMAN-created copy. Copying an open data file without a supported consistency procedure can capture fractured blocks and produce an unusable backup.

A correctly created user-managed data-file copy can be entered in the RMAN repository with CATALOG. The sample path below represents a file that was already copied with an appropriate and tested procedure:

CATALOG DATAFILECOPY '/backup/users01.dbf';

Cataloging the file records its metadata, but the operation does not read and validate every block. It also does not prove that an online copy was made using the consistency steps required for that technology. RMAN-created image copies are preferable for this lesson because RMAN reads the database blocks, protects against fractured blocks, and records the completed copy as part of the operation.

An image copy is not automatically portable across operating systems or hardware platforms merely because it is not stored in an RMAN-proprietary backup-set format. Cross-platform transport remains subject to Oracle-supported source and destination combinations, compatible database settings, endianness, and any required RMAN CONVERT operation. Platform migration should follow the documented cross-platform transport procedure rather than relying on an ordinary file copy.

1. Select the required database files and confirm whether the command applies to the CDB root or a PDB.
2. Choose disk-accessible storage with sufficient capacity, suitable performance, and appropriate permissions.
3. Run an explicit BACKUP AS COPY command and apply a documented tag when it helps identify the copies.
4. Review the RMAN job result and use LIST COPY to inspect the repository records and physical names.
5. Crosscheck and validate according to the backup policy, recognizing that the commands test different conditions.
6. Retain the data-file copies, incremental backups, and redo needed to reach the organization's recovery target.
7. Test the intended restore, switch, and recovery procedure before an emergency occurs.

An RMAN image copy is valuable because it remains a disk-accessible database-file copy while RMAN tracks it for recovery. Its usefulness depends on correct creation, adequate storage, sufficient redo, maintained repository records, and a tested recovery procedure.

In the next lesson, you will learn how RMAN uses multiple channels and multisection processing to create eligible image copies in parallel.