Performing a Consistent Closed Database Backup

A consistent closed backup is created while the database is not open and after Oracle has completed a clean shutdown. At that point, the data file headers reflect a consistent checkpoint. If the complete backup is restored later, the database can normally be opened at the backup point without first applying redo.

The word closed describes the state of the database, not the program that creates the backup. Recovery Manager (RMAN) can back up a database while it is mounted but not open. A DBA can also leave the instance shut down and copy the required files with operating-system or storage tools. These are separate procedures with different safeguards and management responsibilities.

A closed backup requires an outage, so it is not the usual primary strategy for a production database that must remain continuously available. It remains useful for scheduled maintenance, migrations, test systems, and databases operating in NOARCHIVELOG mode. In NOARCHIVELOG mode, a consistent closed backup is the normal supported method for a whole-database backup.

Plan the Backup Before the Outage

Do not begin by shutting down the database. First confirm that the backup environment is ready. A short outage can become a long one if RMAN channels are misconfigured, the destination is full, an encryption key is unavailable, or the backup cannot be written at the expected speed.

Before the maintenance window, complete these checks:

1. Confirm whether the database is operating in ARCHIVELOG or NOARCHIVELOG mode.
2. Verify that the target backup destination has enough capacity and does not share every failure mode with the primary database storage.
3. Review the RMAN configuration, channels, retention policy, encryption requirements, and media-management or cloud connectivity.
4. Confirm that the account used for backup has the required administrative privilege, normally SYSBACKUP or SYSDBA.
5. Protect the TDE wallet or keystore, encryption passwords, credentials, and procedures required to restore encrypted backups.
6. Schedule and communicate the outage, including the time required to validate the result and return the database to service.

RMAN uses persistent configuration settings to determine how and where it writes a backup. Review them before the outage:

RMAN> SHOW ALL;

For a basic disk configuration, RMAN writes to the configured default device. If a fast recovery area is enabled and no explicit FORMAT is supplied, RMAN can create uniquely named backup pieces there. In other environments, configured disk channels, SBT channels, media-management software, Recovery Appliance, or supported cloud integration determine the destination. RMAN does not pause during BACKUP DATABASE to ask where the files should be written.

Enable Control File Autobackups

The control file contains the physical structure of the database and RMAN repository information. The server parameter file contains settings needed to start the instance. Enabling control-file autobackups gives RMAN an independently discoverable copy of these critical recovery assets.

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;

This is a persistent configuration. It does not remove the need to protect the RMAN repository, recovery catalog when one is used, password file, TDE keystore, and environment-specific configuration. A practical recovery plan includes every asset and credential required to reconstruct the database service, not only the data-file backup pieces.

Step 1: Shut Down the Database Consistently

Use a clean shutdown before creating the backup. The recommended command for a planned maintenance window is:

RMAN> SHUTDOWN IMMEDIATE;

SHUTDOWN IMMEDIATE prevents new connections, terminates active calls, rolls back uncommitted transactions, closes the database, and shuts down the instance. It does not wait for every user to disconnect, which makes it more predictable than SHUTDOWN NORMAL during a scheduled outage.

The following shutdown modes can establish a consistent shutdown:

Shutdown command	Behavior	Suitable before a consistent backup?
SHUTDOWN NORMAL	Waits for connected users to disconnect. This is also the default behavior of SHUTDOWN without a clause.	Yes
SHUTDOWN TRANSACTIONAL	Waits for active transactions to finish, then disconnects sessions.	Yes
SHUTDOWN IMMEDIATE	Rolls back uncommitted work and performs a clean shutdown without waiting for users to disconnect.	Yes, and recommended for this procedure
SHUTDOWN ABORT	Stops the instance immediately without a clean close. Instance recovery is required at the next startup.	No

SHUTDOWN ABORT remains available for emergencies, but it must not be treated as the shutdown that establishes a consistent backup. If the instance was aborted or failed unexpectedly, start it so Oracle can perform instance recovery, then shut it down cleanly before continuing. Copying files immediately after an abort produces an inconsistent copy that requires recovery.

Step 2: Mount the Database

For an RMAN closed backup, start the instance and mount the database without opening it:

RMAN> STARTUP MOUNT;

In the mounted state, Oracle has opened the control file and knows the database structure, but the data files are not open for normal user activity. RMAN can discover and back up the database files while the database remains closed.

When there is any doubt about the database's prior state, an administrator can first start the database and perform another clean shutdown before mounting it for backup. The important condition is that the mounted database follows a confirmed consistent shutdown.

Step 3: Back Up the Database with RMAN

Run the whole-database backup through the configured RMAN channels:

RMAN> BACKUP DATABASE;

By default, RMAN creates backup sets. A backup set contains one or more backup pieces in an RMAN-specific format. If an image copy is required instead, the DBA can use BACKUP AS COPY DATABASE. Both forms are recorded in the RMAN repository, but backup sets are the normal default.

RMAN identifies the data files that belong to the target database and reads Oracle blocks through database server sessions. This is safer than a wildcard operating-system command because database files can reside in multiple directories, Oracle Managed Files locations, ASM disk groups, or other managed storage. RMAN also records metadata that it later uses for restore and recovery.

The backup destination must already be configured or supplied in the command. For example, an environment that intentionally uses a local disk path could provide a unique format specification:

RMAN> BACKUP DATABASE
2> FORMAT '/backup/orcl/closed_%d_%T_%U.bkp'
3> TAG 'CONSISTENT_CLOSED_BACKUP';

The %U substitution variable produces a unique backup-piece name. This example is illustrative. A production path, device type, retention policy, encryption policy, and off-host protection strategy must be designed for the actual environment.

Step 4: Reopen the Database

After RMAN reports successful completion, return the database to service:

RMAN> ALTER DATABASE OPEN;

Confirm that the container database opens successfully and that the required pluggable databases are in their intended open modes. Opening the CDB does not by itself prove that every PDB is available exactly as applications expect, so include PDB and service checks in the operational runbook.

Complete RMAN Workflow

The core procedure can be summarized in four commands:

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

This sequence is especially important for a database in NOARCHIVELOG mode. RMAN cannot create a valid whole-database backup of active data files while that database is open. The database must be mounted after a consistent shutdown.

In ARCHIVELOG mode, the same sequence produces a consistent backup, but the outage is optional because RMAN can also create an online backup. Online backups are generally more suitable when application availability is important, provided all redo needed for recovery is retained. The next lesson introduces the requirements and tradeoffs of open database backups.

Step 5: Inspect and Validate the Backup

Do not declare the operation successful merely because the BACKUP DATABASE command finished. First inspect the repository record:

RMAN> LIST BACKUP SUMMARY;

The summary identifies backup sets and copies known to RMAN, including their status, completion time, device type, and tag. It confirms that RMAN recorded the operation, but it does not prove that every required byte can still be read from the backup destination.

Use restore validation to have RMAN select and read the backup data that would be needed to restore the database:

RMAN> RESTORE DATABASE VALIDATE;

Validation checks whether the required backups are available and readable without creating restored data files. RMAN validation can also detect physical corruption. Other commands, such as BACKUP VALIDATE CHECK LOGICAL DATABASE, test current database files and can add logical block checks when that level of inspection is required.

Validation is valuable, but it is not a complete recovery rehearsal. A reliable backup program periodically restores and recovers the database in an isolated environment. That test verifies the runbook, backup catalog, control-file recovery, archived redo availability, TDE keystore access, credentials, storage capacity, and the time required to meet the recovery-time objective.

Recovery Implications of the Logging Mode

Recovery topic	ARCHIVELOG mode	NOARCHIVELOG mode
Consistent closed backup	Supported	Required as the normal whole-database backup method
Open RMAN backup	Supported	Not supported for active data files
Opening after restoring the complete consistent backup	Normally possible at the backup point without media recovery	Normally possible at the backup point without media recovery
Recovery beyond the backup point	Possible when all required redo and recovery assets are available	Changes after the backup generally cannot be recovered

A consistent backup does not guarantee zero data loss. In NOARCHIVELOG mode, restoring the latest closed backup normally discards all changes made afterward. In ARCHIVELOG mode, recovery can proceed farther only if the complete required redo stream and the other recovery assets remain available and usable.

User-Managed Closed Backup Alternative

Oracle AI Database 26ai continues to support user-managed physical backups, but they require more manual control than RMAN. Use this method only when the storage architecture, operational procedures, and recovery plan justify it.

1. Inventory every permanent data file and every current control-file member from database metadata.
2. Record the database identity, logging mode, file locations, storage configuration, and time of the backup.
3. Shut down the database cleanly with SHUTDOWN IMMEDIATE.
4. Leave the instance shut down while an appropriate operating-system or storage utility copies the inventoried data files and control files.
5. Protect the SPFILE or PFILE, password file, TDE wallet or keystore, required credentials, and recovery documentation.
6. Verify file counts, sizes, checksums, destination permissions, and protection from failure or unauthorized deletion.
7. Restart the database with STARTUP and complete application and PDB availability checks.
8. Test the copied files by restoring them in an isolated environment.

Do not use a command such as COPY *.ora as a substitute for the database inventory. Modern Oracle files may not use an old .ora naming convention, and they may not reside in one directory. A wildcard can omit required files or include unrelated files without warning.

Do not copy active online redo log files as part of a normal user-managed backup. Redo-log multiplexing protects availability, but online redo members are not backup copies. Do not copy temporary files either; Oracle can recreate them when required. Archived redo logs are different from active online redo logs and must be retained when they are needed to meet the recovery objective of an ARCHIVELOG database.

RMAN and User-Managed Methods Compared

Topic	RMAN consistent closed backup	User-managed consistent closed backup
Database state	Mounted, not open	Instance shut down
File discovery	RMAN discovers database files from Oracle metadata	The DBA must inventory every required file
Backup representation	Backup sets or image copies	Operating-system or storage copies
Oracle block checks	Integrated with RMAN backup and validation operations	Not supplied by a basic file-copy utility
Repository metadata	Recorded automatically in the RMAN repository	Must be documented; compatible copies can be cataloged later when appropriate
Administrative responsibility	RMAN manages file selection and recovery metadata	The DBA manages file selection, copy consistency, naming, records, and verification
Recommended role	Preferred Oracle backup and recovery method	Specialized alternative for suitable environments

Operational Checklist

Before accepting the backup as a recovery point, verify all of the following:

• The database was shut down consistently before it was mounted or copied.
• The RMAN job completed without errors and the expected backup records appear in the repository.
• The control file and server parameter file are protected, preferably through control-file autobackup.
• The backup destination is separated from the primary storage's failure and administrative boundaries.
• Encryption keys, wallets, passwords, and media-management credentials are accessible under the recovery procedure.
• The CDB, required PDBs, and application services returned to their intended state after the outage.
• RMAN validation can read the required backup data.
• An isolated restore and recovery test has demonstrated that the recovery objectives are achievable.

A closed backup is complete only when it forms part of a usable recovery chain. The backup files, repository metadata, control-file protection, redo needed for the selected recovery target, encryption material, and tested instructions must all be available when a failure occurs.

The next lesson covers the advantages, disadvantages, and requirements of open database backups.

Review your understanding of consistent closed database backup options and procedures.

Performing Backup - Quiz