Lesson 1

Creating and Managing RMAN Backup Sets

Earlier in this course, you learned how Oracle Recovery Manager (RMAN) creates image copies. An image copy has the same logical structure as the data file, archived redo log, or control file from which it was created. Because RMAN can switch a data-file copy into service in appropriate recovery situations, image copies can reduce the time spent restoring a damaged file. An incrementally updated backup strategy can also apply incremental backups to a data-file copy so that the copy is rolled forward without creating a new full copy each time.

This module introduces RMAN's other principal backup format, the backup set. Backup sets remain a first-class backup format in Oracle AI Database 26ai. They can be written to disk or through a System Backup to Tape (SBT) interface, can use RMAN binary compression and encryption, and can be created by multiple channels working in parallel. These capabilities make backup sets useful for on-premises storage, media-management systems, and supported cloud-oriented backup destinations.

By the end of this module, you will be able to:

Explain the relationship among input files, backup sets, and backup pieces.
Use the RMAN BACKUP command to create backup sets.
Explain how and why RMAN multiplexes input files into backup sets.
Configure RMAN channels and parallelism for backup operations.
Create and identify data-file backup sets.
Create and identify archived-redo-log backup sets.

Oracle Autonomous AI Database

Understanding Backup Sets and Backup Pieces

A backup set is a logical RMAN backup that contains data from one or more input files. The physical files that RMAN writes are called backup pieces. A backup set therefore is not necessarily a single operating-system file. It can contain one backup piece or several pieces, depending on the command, channel configuration, media restrictions, and size limits in effect when the backup is created.

Only RMAN should read and interpret the contents of a backup piece. A backup piece is not a byte-for-byte copy that an administrator can place directly in the data-file directory. During a restore, RMAN reads the appropriate backup pieces, reconstructs the requested database files, and then applies redo as needed during recovery. The RMAN repository records the relationships among the source files, backup sets, backup pieces, checkpoints, and completion times so that RMAN can select usable backups during restore and recovery.

RMAN can create backup sets for data files, archived redo logs, control files, and the server parameter file. A data-file backup set can contain full or incremental backups. Archived redo logs are placed in archived-log backup sets rather than mixed into the same backup set as data files. Later lessons in this module examine these backup-set types and their contents in more detail.

Backup sets can save space because RMAN does not need to copy every block from the source file. For example, RMAN can omit certain blocks that have never been used. Binary compression can reduce the backup further when the data is compressible. The resulting storage savings vary with the database, compression setting, encryption state, and workload, so compression should be measured with representative backups rather than assumed to provide a fixed ratio.

Comparing Backup Sets with Image Copies

Backup sets and image copies solve different recovery and storage problems. Neither format is universally superior. A well-designed recovery strategy can use both, such as maintaining incrementally updated copies for selected data files while creating compressed backup sets for longer retention or an off-host destination.

RMAN backup-set and image-copy characteristics
Characteristic	Backup set	Image copy
Physical representation	One or more RMAN backup pieces	A file with the same logical structure as the source file
Disk destination	Supported	Supported
SBT destination	Supported	Not supported
RMAN binary compression	Supported	Not applicable
Use during recovery	RMAN normally restores the required file before recovery	A data-file copy can sometimes be switched into service
Incremental merge	Incremental backup sets provide the changes	The changes can be applied to a data-file copy

The recovery-time objective, backup window, storage capacity, network bandwidth, destination type, and retention policy should determine the format. For example, an image copy can be attractive when fast access to a replacement data file is required and sufficient disk space is available. A backup set can be preferable when storage efficiency, SBT output, encryption, or binary compression is important. Recovery testing is the best way to confirm that the chosen combination satisfies the organization's recovery objectives.

Configuring the Default Disk Backup Type

The RMAN BACKUP command can create either backup sets or image copies on disk. Unless the persistent RMAN configuration has been changed, the default disk backup type is an uncompressed backup set. Before modifying a production configuration, connect RMAN to the target database and review the settings that are already in effect:

SHOW ALL;

Use CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO to select the persistent default format for disk backups. The following command makes image copies the disk default:

CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY;

The following command makes uncompressed backup sets the disk default:

CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO BACKUPSET;

A persistent configuration reduces repetition in scheduled RMAN jobs, but it does not remove the administrator's ability to select a format for an individual operation. Use AS COPY or AS BACKUPSET in a specific BACKUP command when that job must override the configured disk default:

BACKUP AS COPY DATAFILE 7;
BACKUP AS BACKUPSET DATAFILE 7;

The format selected by a command should be intentional. Avoid changing a persistent setting simply to run one exceptional job, because the change can silently affect later scheduled backups. An explicit command-level override documents the exception and leaves the normal configuration unchanged.

Configuring Binary Compression

RMAN binary compression can reduce the amount of storage and network bandwidth required by a backup set. Compression also consumes CPU, and data that is already compressed or encrypted may yield less additional reduction. Database administrators should compare backup duration, CPU use, backup size, restore performance, and licensing requirements before standardizing a compression policy.

Use the following commands to configure compressed backup sets as the persistent default for disk and SBT devices:

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

To return to uncompressed backup sets, configure the device again without the COMPRESSED keyword:

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

You can also request compression for one operation without changing the persistent device configuration:

BACKUP AS COMPRESSED BACKUPSET DATABASE;

Binary compression is distinct from RMAN's ability to avoid backing up blocks that do not need to be included. The two behaviors can both reduce backup size, but they work differently. Binary compression encodes the data written into a backup piece, while block-selection optimizations reduce the amount of source data supplied to the backup in the first place.

Backup Sets in a Multitenant Database

Oracle AI Database 26ai uses the multitenant architecture. RMAN can protect an entire container database (CDB), individual pluggable databases (PDBs), tablespaces, or selected data files, subject to the command and connection context. A backup set can therefore participate in CDB-level recovery as well as operations scoped to a PDB.

The recovery strategy must still protect all required supporting information. A complete design accounts for the control file, server parameter file, archived redo logs, encryption keys, and the RMAN repository in addition to application data files. If transparent data encryption is used, protecting and testing access to the keystore is essential. A valid backup piece is not sufficient for recovery when a required encryption key is unavailable.

The optional recovery catalog does not store the backup data itself. It stores RMAN metadata and can provide longer history, centralized reporting, and stored scripts. Whether metadata resides only in the target control file or is also synchronized to a recovery catalog, the physical backup pieces must remain accessible at restore time.

How Channels Affect Backup-Set Creation

An RMAN channel represents a stream of work between RMAN and a storage device. A disk channel writes backup pieces to disk, while an SBT channel passes backup data to the configured media-management or cloud library. Multiple channels can create different backup sets or file sections concurrently when the storage system, CPU resources, and input devices can support the additional work.

RMAN can also multiplex blocks from multiple input files into a backup piece. Multiplexing can keep a sequential output device busy when individual input files cannot supply data quickly enough. Excessive multiplexing, however, can affect restore behavior. Multisection backups address a different problem by dividing a large data file into sections that multiple channels can process. Later lessons explain how channel parallelism, multiplexing, FILESPERSET, MAXOPENFILES, and section size interact.

Parallelism should not be treated as a guarantee that every backup will complete proportionally faster. Throughput can be limited by source disks, database workload, CPU capacity, network bandwidth, destination latency, media-manager behavior, or the number of available SBT streams. Increase parallelism only after measuring the complete data path and confirming that restore performance remains acceptable.

Creating an Initial Backup Set

After reviewing the configuration and confirming the destination, the following command explicitly requests a database backup in backup-set format:

BACKUP AS BACKUPSET DATABASE;

A commonly used variation backs up the database and the archived redo logs needed to make the backup recoverable through the end of the operation:

BACKUP AS BACKUPSET DATABASE PLUS ARCHIVELOG;

The exact production command depends on the archiving configuration, retention policy, backup optimization setting, deletion policy, destination, and recovery requirements. For that reason, a short example should not be copied into a production scheduler without reviewing the complete recovery design. In particular, any use of archived-log deletion clauses must be coordinated with Data Guard, downstream consumers, and the organization's retention requirements.

When a fast recovery area is configured and no explicit disk format is supplied, RMAN can generate unique names and place disk backup pieces in the appropriate recovery-area location. Other environments use a channel FORMAT setting, an SBT library, or a supported cloud integration. Storage placement should be verified rather than inferred from the success message alone.

Verifying the Configuration and Backup

A completed command is the beginning of backup validation, not the end. Use RMAN reporting commands to confirm what was created and which configuration controlled the operation:

SHOW ALL;
LIST BACKUP SUMMARY;
LIST BACKUP OF DATABASE;

LIST BACKUP SUMMARY provides a compact inventory, while a detailed LIST BACKUP command shows backup sets and their pieces. The repository metadata should agree with the files or media known to the destination. If files have been moved or removed outside RMAN, use appropriate repository-maintenance procedures so that RMAN does not plan a restore around unavailable pieces.

Validation should also include periodic restore and recovery tests on an isolated system. A restore test confirms more than readability. It exercises credentials, SBT or cloud-library access, encryption-key availability, network paths, capacity planning, and the documented recovery procedure. The result provides evidence that the backup strategy can meet its recovery-time and recovery-point objectives.

Planning the Module

Backup sets are a standard and widely applicable RMAN format, but their effectiveness depends on how they are configured and managed. In the remaining lessons, you will move from the logical backup-set concept to the operational details of the BACKUP command, backup pieces, multiplexing, parallel channels, data-file backup sets, and archived-redo-log backup sets. Keep the distinction between a logical backup set and its physical backup pieces in mind, because that relationship explains much of RMAN's backup and restore behavior.

In the next lesson, you will examine what a backup set contains and how RMAN organizes backup data into backup pieces.