Using the RMAN BACKUP Command and Tags

Yes. Oracle AI Database 26ai Recovery Manager (RMAN) continues to support tags with the BACKUP command. A tag is a reusable, case-insensitive label recorded in the RMAN repository for backup output. It helps administrators recognize and select related backups without changing what the backup contains, where it is stored, or how long it is retained.

Lesson 4 explained how RMAN channels provide server-side I/O streams. The BACKUP command describes the work assigned to those channels: which database objects RMAN should read, which output form it should create, and which optional settings apply. This lesson introduces that command and then focuses on the tags used to identify its output.

How the RMAN BACKUP Command Works

The BACKUP command is RMAN's primary command for creating backup sets and image copies. It can be issued directly at the RMAN prompt when suitable automatic channels are available. It does not have to be enclosed in a RUN block, and a basic disk backup does not require an explicit ALLOCATE CHANNEL command. RMAN includes a preconfigured default DISK channel and can use other persistent channel settings created with CONFIGURE.

A RUN block remains useful when a compound job needs manually allocated channels, job-scoped settings, or several coordinatedccommands. Manual channels temporarily override applicable automatic channel settings for that job. Whether channels are automatic or manual, their database-server sessions perform the physical reads, processing, and writes requested by BACKUP.

The simplest whole-database example is:

BACKUP DATABASE;

When RMAN is connected to a CDB root with the required administrative privilege, this command selects the data files in the whole-CDB scope. When RMAN is connected directly to a PDB with the required privilege, BACKUP DATABASE operates within that PDB's scope. The default output is a backup set, and RMAN uses the configured default device type and available channels.

The command does not automatically mean BACKUP DATABASE PLUS ARCHIVELOG. Archived redo logs must be selected explicitly, either with an archived-log backup specification or an option such as PLUS ARCHIVELOG. Control file and server parameter file handling depends on the command scope, whether data file 1 is included, how the instance was started, and the configured control file autobackup setting.

RMAN protects Oracle database files, but it is not an operating system backup utility. Oracle Net configuration files, password files, the Oracle home, block change tracking files, and external BFILE content are not ordinary inputs to the RMAN BACKUP command. A complete protection plan must address those assets separately when they are required for recovery or rebuilding a server.

Backup Sets and Image Copies

The output form and the source scope are separate decisions. AS BACKUPSET and AS COPY determine the output form. Keywords such as DATABASE, PLUGGABLE DATABASE, TABLESPACE, DATAFILE, ARCHIVELOG, and CURRENT CONTROLFILE identify source objects through backup specifications.

BACKUP AS BACKUPSET DATABASE;
BACKUP AS COPY DATABASE;

Backup sets can be written through DISK or SBT channels. SBT destinations include supported media-management, cloud, and recovery-service integrations. Image copies require disk-accessible storage. Lesson 6 examines image copies more closely, including why their data-file format supports uses that differ from those of backup sets.

One backup specification can result in more than one backup set. RMAN may divide work according to the selected files, available channels, FILESPERSET, output-size controls, and other command settings. A channel can create multiple backup sets sequentially during a job. It is not permanently limited to one backup set.

Full and Incremental Backups

The output form should not be confused with the incremental level. A backup set or eligible image copy can contain a full or level 0 backup. Level 1 incremental backups are backup sets. The incremental level determines which data blocks RMAN includes and whether the result participates in an incremental backup strategy.

BACKUP DATABASE TAG 'WEEKLY_FULL';
BACKUP INCREMENTAL LEVEL 0 DATABASE TAG 'WEEKLY_L0';
BACKUP INCREMENTAL LEVEL 1 DATABASE TAG 'DAILY_L1';
BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE TAG 'WEEKLY_CUM_L1';

A full backup and an incremental level 0 backup are identical in content, but only the level 0 backup can serve as the parent of a level 1 incremental backup. A level 0 does not contain only changes since an earlier level 0. It establishes or refreshes the baseline by backing up all blocks that have ever been used in the selected data files.

A differential level 1 normally contains fewer blocks because it begins with the most recent level 0 or level 1 incremental backup. A cumulative level 1 always returns to the most recent level 0 baseline. Cumulative backups can require more time and storage than differential backups, but recovery may need fewer level 1 backups because the latest cumulative backup contains all changes since that level 0.

How RMAN Tags Work

A tag is a user-defined or RMAN-generated identifier associated with backup output. For a backup set, the tag is an attribute of each backup piece in a particular copy of that set. For AS COPY, it is an attribute of each image copy. Tags can also be applied to supported proxy copies and control file copies.

Tag metadata belongs to the RMAN repository. The target database control file always stores RMAN repository information. When a recovery catalog is used, catalog metadata also represents the target's backup history. A recovery catalog is therefore not required merely to create, list, or use an ordinary tag.

A tag is a label, not a unique key. The same tag can be reused by a weekly job, so several backup sets or image copies may have the same value. When a command selects by tag, more than one repository record may match. RMAN then applies the selection rules and recovery requirements of that command to identify usable backups. A meaningful tag improves recognition, but it does not guarantee uniqueness.

Tags also do not create retention rules. A tag does not exempt a backup from the configured retention policy, make it immutable, select a storage device, or prove that the files are available and recoverable. Retention configuration, KEEP options, crosschecks, validation, monitoring, and recovery testing address those separate responsibilities.

Tag Rules and Default Tags

RMAN tags are not case-sensitive and are stored in uppercase. For a portable convention, use short ASCII names of no more than 30 bytes. Tag characters must be legal in file names on the target database file system. For example, a hyphen is not valid in a tag for backups stored in an Oracle ASM disk group. Letters, digits, and underscores are safer choices across common destinations.

Environment variables and RMAN format substitutions such as %T and %D are not valid tag content. Those substitutions belong to file-name formats, not tag generation. Suitable reusable names include WEEKLY_FULL, WEEKLY_L0, DAILY_L1, and HRPDB_MONTHEND.

If an ordinary backup does not specify a tag, RMAN generates one, except for control file autobackups, in the following form:

TAGYYYYMMDDTHHMMSS

The date and time represent the start of the backup. Multiple pieces created by one backup operation can share the generated value. This default is useful for identification, but a documented naming convention can communicate purpose, scope, and backup cycle more clearly. Reusing a name such as WEEKLY_L0 is valid when administrators expect the tag to represent a continuing strategy rather than one unique execution.

Command-Level and Backup-Specification Tags

The position of TAG determines its scope. A command-level tag applies to all backup output created by the command. A tag placed in an individual backup specification applies to output from that specification. If both levels provide tags, the backup-specification tag takes precedence for its own output.

This command applies one tag across the database and archived-log work generated by the operation:

BACKUP TAG 'WEEKLY_CDB'
  DATABASE PLUS ARCHIVELOG;

Different specifications can receive different tags when the job needs separate labels:

BACKUP
  (DATABASE TAG 'WEEKLY_DATABASE')
  (ARCHIVELOG ALL TAG 'WEEKLY_ARCHIVELOG');

The parentheses group specifications that have independent options. They are useful when one command assigns separate settings, tags, or channels to different source groups. They are not a requirement around every backup specification in every valid form of the BACKUP command.

Finding and Using Tagged Backups

A tagging practice is most useful when administrators verify the repository record after the job. LIST BACKUP SUMMARY presents a compact inventory that includes a tag column. A tag-specific listing restricts the report to matching records:

LIST BACKUP TAG 'WEEKLY_FULL';
LIST BACKUP SUMMARY;

Supported recovery and maintenance commands can also select backup records by tag. The following restore asks RMAN to consider the tagged backups that satisfy the database restore requirements:

RESTORE DATABASE FROM TAG 'WEEKLY_FULL';

A tag can also identify existing backup sets as the input to another backup operation:

BACKUP BACKUPSET FROM TAG 'WEEKLY_FULL';

This command creates another backup of matching existing backup sets. It does not read the current live data files as a new database backup. Tags can likewise participate in supported CHANGE, DELETE, and recovery selections, although each command has its own matching and precedence rules.

A successful tag lookup does not prove recoverability. Administrators must still review job status, preserve the archived redo required by the recovery objective, reconcile repository records with storage when appropriate, validate backup integrity, and test representative restore and recovery procedures.

TAG Versus WITH TAG

An ordinary TAG clause labels newly created backup output. The specialized WITH TAG clause identifies an incrementally updated image-copy strategy. In that strategy, a level 1 incremental backup contains changes intended to roll forward a level 0 image copy with the same strategy tag.

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

RMAN assigns new incremental output the strategy's tag when WITH TAG is used. If a command includes both an ordinary TAG value and WITH TAG, RMAN warns that the ordinary value is ignored for this operation. Lesson 6 introduces the image copies that form the level 0 foundation of this technique.

Tags and KEEP Backups

A tag and a KEEP option serve different purposes. KEEP UNTIL or KEEP FOREVER changes how a backup interacts with retention processing. The tag labels the output but does not create that retention exemption. A BACKUP ... KEEP operation can produce several related backup sets, and a command-level tag helps associate them.

When KEEP is combined with INCREMENTAL LEVEL, the parent must also be a KEEP backup with the same tag. KEEP FOREVER requires a recovery catalog, but an ordinary tag and other supported KEEP uses do not automatically impose that catalog requirement.

Backup Tags in a CDB or PDB

In a multitenant environment, connection context and object selection determine backup scope. A common administrative user connected to the CDB root can back up the target CDB or select one or more PDBs explicitly. A direct PDB connection limits supported operations to that PDB's scope. Administrative RMAN work requires an appropriate privilege, commonly SYSBACKUP.

BACKUP PLUGGABLE DATABASE hr_pdb
  TAG 'HRPDB_MONTHEND';

This command creates backup output for hr_pdb and records the supplied tag. The tag describes the output, but the PDB selection in the backup specification establishes the scope.

Explicit and Default Tag Comparison

Use a documented tag convention to make backup output easier to recognize and select, but rely on RMAN configuration, retention policy, validation, and recovery testing to make the backup strategy dependable.

In the next lesson, you will learn how RMAN image copies differ from backup sets and how BACKUP AS COPY creates disk-accessible copies of database files.

Allocate Backup Commands - Quiz