Lesson 1

Physical Backups With and Without Archiving

A database backup strategy should be designed before the database carries production data. The important decisions are not limited to where a backup file will be stored. You must decide how much data the organization can afford to lose, how quickly service must be restored, which failures the strategy must survive, and how recovery procedures will be tested.

These requirements are commonly expressed as a recovery point objective, or RPO, and a recovery time objective, or RTO. The RPO describes the maximum acceptable period of data loss. The RTO describes the maximum acceptable time needed to restore service. Together, they influence the database logging mode, backup frequency, archived redo retention, backup destinations, automation, and restore-testing schedule.

Oracle AI Database 26ai supports physical backups in both ARCHIVELOG and NOARCHIVELOG mode. The logging mode determines whether active data files can be backed up while the database is open and how far the database can be recovered after files are restored. For most production databases, ARCHIVELOG mode is the appropriate choice because it supports online backups and a much broader range of recovery operations.

After completing this module, you will be able to:

Explain when user-managed operating-system copies are appropriate and why Recovery Manager is normally preferred.
Describe the recovery implications of consistent and inconsistent physical backups.
Compare consistent closed backups with online backups.
Identify current control-file backup methods, including RMAN control-file autobackups.
Explain how LOGGING and NOLOGGING operations affect recoverability.
Describe backup considerations for read-only tablespaces.
Identify RMAN commands and dynamic performance views used to inspect backup and recovery status.

Physical Backup Fundamentals

A physical backup protects the files that constitute an Oracle database or stores those files in an RMAN-specific representation. The protected content can include data files, control files, the server parameter file, and archived redo logs. An Oracle Data Pump export is a logical backup. It can be valuable for object-level movement and recovery, but it is not a substitute for a physical backup and cannot perform complete media recovery.

Recovery Manager, usually called RMAN, is Oracle's preferred tool for physical backup and recovery. RMAN understands Oracle block structures, records backup metadata, detects many forms of corruption, coordinates backup and recovery operations, and can determine which backups and redo are needed for a requested recovery. User-managed file copies remain available for specialized procedures, but the administrator must coordinate file state, metadata, consistency, and recovery requirements correctly.

RMAN can create two principal forms of physical backup:

Backup sets contain one or more backup pieces in an RMAN-specific format. RMAN can omit blocks that have never been used and can apply compression or encryption when configured.
Image copies are byte-for-byte copies of data files, control files, or archived redo logs. They can be switched into service or updated by applying incremental backups in an incrementally updated backup strategy.

The backup format does not by itself determine whether recovery is possible. Recoverability depends on the state of the database when the backup was taken and on whether all required redo and other recovery assets remain available.

Consistent and Inconsistent Backups

A consistent backup is created after a consistent shutdown. All data files are checkpointed to a consistent system change number, or SCN, and do not require redo merely to become mutually consistent after they are restored. A shutdown performed with NORMAL, IMMEDIATE, or TRANSACTIONAL can produce this state.

A backup made while the database is open is generally an inconsistent backup. Different data-file blocks can reflect different points in time because transactions and database writer activity continue during the backup. This condition does not make an RMAN online backup defective. RMAN coordinates the backup and, when necessary, rereads blocks that changed while they were being copied. During recovery, Oracle applies redo to bring the restored files to a consistent recovery point.

A database stopped by SHUTDOWN ABORT, an instance failure, or a power failure has not undergone a consistent shutdown. A file copy made immediately after such an event must not be treated as a consistent backup. In ARCHIVELOG mode, an inconsistent backup can be recoverable when the required redo exists. In NOARCHIVELOG mode, the missing archived redo makes that approach unsuitable.

You can check the database logging mode with the following query:

SELECT log_mode
FROM   v$database;

Physical Backups in ARCHIVELOG Mode

In ARCHIVELOG mode, Oracle copies a filled online redo log to one or more archived redo log destinations before the log can be reused. This preserved redo history is what allows Oracle to recover restored data files beyond the checkpoint recorded in a backup.

RMAN can back up an ARCHIVELOG database while it is open. Applications can continue to read and modify data while RMAN backs up the active data files. The database can also be mounted or closed for backup when operational requirements permit. For an RMAN backup, administrators do not place tablespaces in backup mode. RMAN provides the block-level handling needed to create a usable online backup.

A useful introductory command is:

BACKUP DATABASE PLUS ARCHIVELOG;

This command backs up the database and archived redo logs as part of one RMAN operation. Data files and archived redo logs are still stored in separate backup sets because RMAN does not mix them in the same backup set. A production script also needs environment-specific destination, retention, encryption, channel, monitoring, and error-handling decisions.

After an online backup is restored, RMAN uses archived redo and, when available and needed, online redo to make the restored files consistent and advance them toward the requested recovery point. If every required change is available, complete media recovery may return the database to the latest possible point. Database point-in-time recovery can instead stop at a selected time, SCN, restore point, or other supported boundary.

ARCHIVELOG mode also supports recovery capabilities expected in recoverable production environments, including online backups, block media recovery, database point-in-time recovery, Data Guard configurations, and Flashback Database when each feature's additional prerequisites are met. Logging mode alone does not guarantee zero data loss. The outcome still depends on the backups, archived logs, online redo, standby protection, storage state, and failure scenario.

Physical Backups in NOARCHIVELOG Mode

In NOARCHIVELOG mode, Oracle can reuse filled online redo logs without first preserving them as archived redo. The database therefore does not retain the continuous redo history needed to recover an online backup or advance a restored database through all changes made since the backup.

The normal supported strategy is a consistent whole-database backup. Shut down the database cleanly, start it in mounted state, run the backup, and then open it:

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
BACKUP DATABASE;
ALTER DATABASE OPEN;

Mounting the database allows RMAN to access the control file without permitting users to modify active data files. After this consistent backup is restored, media recovery is not normally required merely to open the database at the backup point. However, transactions committed after the backup cannot be recovered from archived redo because that redo history was not retained.

An open NOARCHIVELOG database cannot be fully protected by an online physical backup of its active data files. Each backup requires downtime, and recovery generally returns the database to the latest valid consistent backup. This combination of downtime and potential post-backup data loss usually limits NOARCHIVELOG mode to noncritical, reproducible, or disposable databases whose business requirements explicitly accept those constraints.

Capability	`ARCHIVELOG` mode	`NOARCHIVELOG` mode
RMAN backup while the database is open	Supported	Not supported for active data files
Consistent closed backup	Supported	Required as the normal whole-database method
Redo required after restoring an online backup	Yes	An online backup of active data files is not available
Complete recovery after media failure	Possible when all required backups and redo are available	Generally limited to the consistent backup point
Database point-in-time recovery	Supported when the required backups and redo exist	Not supported from unarchived redo history
Expected production use	Normal choice for systems that require recoverability	Appropriate only when downtime and post-backup data loss are acceptable

Build a Complete Recovery Chain

The legacy expression redundancy set attempted to describe everything needed after a media failure. A clearer current model is the recovery chain: the complete set of database backups, redo, metadata, security material, infrastructure configuration, and procedures needed to reach an intended recovery point.

The database portion of a recovery chain can include:

valid data-file backups, backup sets, or image copies;
all archived redo logs and incremental backups required from the selected backup checkpoint to the intended recovery point;
current control-file backups and RMAN control-file autobackups;
the server parameter file, plus any required text initialization file;
RMAN repository metadata in the target control file and, when used, a protected recovery catalog;
the database identifier, backup encryption passwords, and enough documentation to locate and restore the correct backup generation.

Configure RMAN control-file autobackups so that RMAN creates an independent backup containing the control file and the server parameter file:

CONFIGURE CONTROLFILE AUTOBACKUP ON;

The control file contains essential physical structure and RMAN repository information. The well-known autobackup naming pattern helps RMAN locate the control file and server parameter file even when the current control file and recovery catalog are unavailable. The autobackup must still be stored and retained where it can survive the failure being planned for.

A practical recovery also depends on assets that are not themselves database physical backups. These can include password files, Oracle wallets, Transparent Data Encryption keystores, encryption credentials, Oracle Net configuration, listener configuration, storage mappings, media-management software configuration, cloud credentials, and recovery runbooks. Losing a TDE keystore or the credential needed to access protected storage can make otherwise valid backup pieces unusable.

Protect these dependencies according to their security requirements. Do not describe tnsnames.ora, listener.ora, a wallet, or a recovery runbook as an RMAN database backup. They are separate disaster-recovery assets that may be required to rebuild database services.

Separate Recovery Copies from Primary Storage

Keep at least one recoverable backup copy outside the failure domain and administrative boundary of the primary database storage. A different directory or logical volume is not enough when both locations depend on the same storage array, controller, host, credentials, administrator account, availability zone, or region.

Failure-domain separation should consider more than hardware:

Storage: Avoid placing every recovery copy on the same disks, array, file system, ASM disk group, or storage service as the primary database.
Compute and location: Retain an appropriate copy away from the database host and, when required by the recovery plan, in another site, availability zone, or region.
Administration: Prevent one compromised or mistaken account from deleting both production data and every backup.
Immutability and retention: Use supported controls that prevent premature modification or deletion of protected recovery points.
Encryption: Protect backup data and preserve the keys and credentials through an independent, tested process.

RMAN backups can be written to disk or a fast recovery area, through supported SBT media-management channels, to supported cloud object storage, to tape, or to a Recovery Appliance. The correct destination depends on recovery objectives and architecture. Whatever destination is chosen, it must not share every failure mode with the database it protects.

Redundancy Improves Availability but Does Not Replace Backups

Multiplexed online redo log members, multiplexed control files, ASM redundancy, RAID, storage snapshots, and replication can improve availability and reduce recovery time for selected failures. They do not replace independent, tested backups. Replication or mirroring can faithfully reproduce logical corruption, accidental deletion, ransomware damage, or an unwanted application change.

When the architecture permits, multiplex online redo log members and control-file members across independent storage paths. These are active database files maintained for fault tolerance, not backup copies. Back up the control file independently, preferably with RMAN autobackup enabled. Do not copy live online redo log files with operating-system commands as part of a normal physical backup strategy.

Retain multiple recovery points rather than depending only on the most recent backup. If corruption or an unwanted change existed before the newest backup was created, an older validated backup may be essential. Retention should be based on business recovery requirements, not simply on available disk space.

User-Managed Backups and Storage Snapshots

User-managed physical backups remain documented in Oracle AI Database 26ai, but they are a specialized alternative to RMAN. A consistent user-managed whole-database backup requires a clean shutdown before operating-system tools copy the required files. For copies or storage snapshots of files belonging to an open database, follow Oracle-compatible snapshot requirements or use the applicable ALTER DATABASE ... BEGIN BACKUP and END BACKUP procedure.

A crash-consistent storage snapshot is not automatically an application-consistent Oracle backup. The database state, snapshot technology, redo requirements, and recovery procedure must be validated together. Oracle AI Database 26ai desupports the former RECOVER ... SNAPSHOT TIME method. Current snapshot recovery designs should use supported backup-mode procedures and recovery to a time or SCN, together with a storage vendor integration validated for the Oracle workload.

LOGGING, NOLOGGING, and Read-Only Data

ARCHIVELOG mode preserves generated redo, but it cannot reconstruct changes that were not fully recorded. A significant NOLOGGING operation can create data-file changes for which redo is insufficient for complete reconstruction. Back up affected data files after such operations so that the recovery chain contains a usable representation of the changed blocks.

Read-only tablespaces can reduce repeated backup work because their blocks do not change while the tablespace remains read-only. Their backups must still be retained, and the control-file metadata describing the tablespaces and data files must remain available. Later lessons examine the detailed backup implications of NOLOGGING operations and read-only tablespaces.

Validate Backups and Test Recovery

A completed backup job is evidence that RMAN wrote output, but it is not proof that the organization can restore the database within its RTO or recover it to its RPO. Operational verification should include monitoring RMAN job completion, reviewing warnings and errors, synchronizing repository records with storage, validating backup pieces, and performing isolated restore and recovery tests.

RMAN provides complementary checks:

CROSSCHECK BACKUP;
RESTORE DATABASE VALIDATE;
BACKUP VALIDATE CHECK LOGICAL DATABASE ARCHIVELOG ALL;

CROSSCHECK compares repository records with the files known to the configured storage device. RESTORE ... VALIDATE checks whether RMAN can read the backups needed for a restore without writing restored data files. BACKUP ... VALIDATE reads database files as if performing a backup, and CHECK LOGICAL adds logical block checks to physical validation.

Validation commands are valuable, but an isolated restore and recovery test provides stronger evidence. A test should verify access to backup destinations, credentials, encryption keys, wallets, media libraries, network paths, compatible software, and sufficient storage capacity. It should also measure elapsed restore and recovery time and confirm that the recovered database can be opened and checked safely.

Planning the Backup Strategy

Before a database enters production, document decisions for each of the following questions:

What RPO and RTO apply to the database and to its most important services?
Does the database run in ARCHIVELOG mode, and how long must archived redo remain recoverable?
Which full, incremental, archived redo, control-file, and server parameter file backups form each recovery chain?
Where are the backups stored, and which physical and administrative failures can each copy survive?
How are backup encryption keys, TDE keystores, passwords, and storage credentials protected and recovered?
How are backup failures detected, escalated, and corrected?
How often are isolated restore tests performed, and do measured results satisfy the recovery objectives?

The strategy should be revised when database size, workload, storage architecture, legal retention, security controls, or recovery objectives change. A recoverable design combines backups, retained redo, protected metadata, independent storage, secure access, monitoring, and practiced procedures.

The next lesson introduces basic database backup concepts.