User-Managed Operating System Backup Options

A user-managed physical backup is a copy of Oracle database files made with an operating-system utility, a storage utility, or an approved snapshot mechanism. The database administrator uses SQL or SQL*Plus commands to place the database files in an appropriate state, identifies every file that must be protected, creates the copies, and preserves the redo and metadata needed for recovery.

Oracle AI Database 26ai continues to support this approach for self-managed databases. However, Recovery Manager (RMAN) is the preferred tool for routine production backup and recovery. RMAN understands Oracle block structures, discovers database files, records backup metadata, checks for fractured blocks, supports incremental backups, and integrates backup validation, compression, encryption, and media-management destinations. An ordinary file-copy program does not provide those safeguards.

It is important to separate two decisions that the legacy terminology sometimes combines:

• Backup method: RMAN or a user-managed operating-system copy.
• Database logging mode: ARCHIVELOG or NOARCHIVELOG.

The logging mode determines which user-managed backup procedures are safe and how far the database can be recovered. A consistent closed backup can be made in either mode. An online or otherwise inconsistent user-managed backup requires ARCHIVELOG mode and all redo needed to make the restored files consistent.

Oracle AI Database 26ai uses the multitenant architecture. A container database (CDB) contains the root and one or more pluggable databases (PDBs). Consequently, the administrator must know whether a procedure protects the complete CDB or the data files of a particular PDB, and must connect to the correct container with the required SYSDBA or SYSBACKUP privilege.

Check the Logging Mode First

Before selecting a procedure, check the current logging mode:

SELECT log_mode
FROM   v$database;

In ARCHIVELOG mode, Oracle archives a filled online redo log before that log can be reused. Retaining the required archived redo gives media recovery a history of database changes to apply after a backup is restored. In NOARCHIVELOG mode, online redo logs can be reused without preserving that history. This substantially limits recovery after a media failure.

Capability	ARCHIVELOG mode	NOARCHIVELOG mode
Consistent closed user-managed backup	Supported	Supported and the normal safe whole-database method
Online user-managed backup of read/write data files	Supported when the files are placed in backup mode	Not supported as a recoverable strategy
Recovery after restoring an inconsistent backup	Possible when every required redo record is available	Not possible from overwritten, unarchived redo
Recovery beyond the last consistent backup	Possible when the recovery chain is complete	Generally unavailable
Database point-in-time recovery	Available within retained backup and redo coverage	Not available from unarchived redo history

Oracle Autonomous AI Database

Consistent and Inconsistent Backups

A consistent backup is created when the database files are at a consistent system change number (SCN). For a complete CDB, this normally means shutting down with SHUTDOWN NORMAL, SHUTDOWN IMMEDIATE, or SHUTDOWN TRANSACTIONAL before copying the files. A clean shutdown checkpoints the data files and makes their contents consistent with the control file. If the complete backup is later restored, it can ordinarily be opened at the backup point without media recovery. If the database was in ARCHIVELOG mode, additional redo may be applied to recover it to a later point.

An inconsistent backup contains files that are not all consistent at one SCN. A backup made while the database is open is inconsistent. A copy made after an instance failure or SHUTDOWN ABORT is also inconsistent because crash recovery has not yet made the files consistent. After restoring such a backup, Oracle must apply redo during media recovery before opening the database.

An inconsistent backup must not be used as the protection strategy for a NOARCHIVELOG database. The redo required to make the restored files consistent may already have been overwritten. For that logging mode, the dependable rule is to perform a complete backup after a clean shutdown.

An ARCHIVELOG database supports both consistent closed backups and online user-managed backups. The online option improves availability because applications can continue to use the database while its data files are copied. The tradeoff is that the restored copies require redo, and the administrator must correctly coordinate backup mode, archived redo retention, control-file protection, and recovery testing.

The figure shows the essential relationship among database files, backup mode, the operating-system copy, and the archived redo required for recovery. The backup copy alone is not a complete recovery chain. The administrator must retain all archived redo logs needed from the backup's checkpoint through the selected recovery target, along with the necessary control-file metadata and security material.

Why Online User-Managed Backups Need Backup Mode

An operating-system utility copies bytes without understanding Oracle block boundaries. While DBWR is writing a data block, a copy utility could read one portion before the database write and another portion afterward. The resulting copy contains a fractured block whose header and footer do not describe one consistent version of the block.

Before copying the data files of an online read/write tablespace, place that tablespace in backup mode. End backup mode immediately after the copy finishes, and force the current redo to be archived:

ALTER TABLESPACE users BEGIN BACKUP;

-- Copy every data file belonging to USERS with an approved OS or storage utility.

ALTER TABLESPACE users END BACKUP;
ALTER SYSTEM ARCHIVE LOG CURRENT;

If all applicable data files are copied together, the database-wide form can bracket the copy:

ALTER DATABASE BEGIN BACKUP;

-- Copy the applicable data files.

ALTER DATABASE END BACKUP;
ALTER SYSTEM ARCHIVE LOG CURRENT;

Backup mode freezes the checkpoint information in the data-file header and causes complete images of changed blocks to be written to redo. That extra information enables recovery to repair a fractured block in the copy. It can also generate substantially more redo during a busy workload, so files should remain in backup mode only for the required copy interval.

After a failed copy, instance failure, or interrupted script, verify that no data files remain in backup mode:

SELECT file#, status, change#, time, con_id
FROM   v$backup
WHERE  status = 'ACTIVE';

Do not issue an indiscriminate END BACKUP after files have been restored. The correct response depends on whether the files are current or restored copies that require recovery. This is one reason user-managed recovery procedures require careful runbooks and testing.

Recovery Capabilities and Limits

With a valid backup and a complete redo history, an ARCHIVELOG database can support complete media recovery or database point-in-time recovery. Complete recovery attempts to apply all available changes and return the database to the most current possible state. Point-in-time recovery deliberately stops at a selected time, SCN, or other supported recovery boundary.

ARCHIVELOG mode does not itself guarantee zero data loss or recovery to the exact failure point. A required archived redo log may be missing, an online redo member may be damaged, a backup may be corrupt, or encryption material may be unavailable. The achievable recovery point is determined by the usable backup and redo chain that survives the incident.

For a database operating in NOARCHIVELOG mode, use a consistent closed whole-CDB backup as the normal user-managed method. The database must be shut down cleanly before the files are copied. A simple teaching outline is:

SHUTDOWN IMMEDIATE;

-- Copy all required data files and every control-file member.

STARTUP;

This is an abbreviated pattern, not a complete production script. A real procedure must obtain the authoritative file list, select protected destinations, check copy failures, preserve initialization and security files, and document how the files will be restored.

After a media failure, restoring this backup normally returns the database to the state captured at the backup point. Transactions committed after the backup cannot be reconstructed from archived redo because those logs were not retained. The amount of potential data loss therefore equals the work performed since the most recent usable consistent backup.

NOARCHIVELOG mode may be acceptable for a disposable development database or another system whose owners accept backup downtime and loss of post-backup changes. It is usually unsuitable when a production recovery-point objective requires recovery beyond the most recent closed backup.

SELECT tablespace_name, file_name
FROM   dba_data_files
WHERE  tablespace_name = 'USERS';

ALTER TABLESPACE users OFFLINE NORMAL;
-- Copy every listed USERS data file.
ALTER TABLESPACE users ONLINE;
ALTER SYSTEM ARCHIVE LOG CURRENT;

ALTER DATABASE BEGIN BACKUP;
-- Copy the data files belonging to the connected PDB.
ALTER DATABASE END BACKUP;

ALTER DATABASE BACKUP CONTROLFILE TO '/backup/cf.bak' REUSE;