Australian cloud for business software — built and run in Sydney since 2003

+61 2 8282 5656
support@netleverage.com
Talk to an engineer
Talk to an engineer
NetLeverage
NetLeverage

Oracle RMAN on a physical server: what you need to restore from nothing

Technical article
Backup & Recovery

Originally published:

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.

Oracle Recovery Manager (RMAN) is the standard tool for backing up Oracle databases. On a virtual machine, a whole-machine image may hide gaps in an RMAN setup. On a physical server, when the machine is gone, what RMAN wrote is all you have.

Oracle's documentation is specific about what that must include. This guide explains each item, shows where control file autobackups go by default, and distinguishes repository reports from scheduled backup validation, which can update diagnostic and corruption records.

Why it matters

An RMAN restore onto a new server starts with almost nothing: no parameter file, no control file and no record of where backups are (our reading). The control file is where RMAN keeps its record by default. Oracle states: "RMAN repository metadata is always stored in the control file of the target database." If that control file is lost with the server and there is no recovery catalog, RMAN has to find a backup of it first, and it needs the database's identifier to do so.

Oracle's four prerequisites

The Backup and Recovery User's Guide lists the prerequisites for disaster recovery. "You must have the following:"

  • "Backups of all data files"
  • "All archived redo logs generated after the creation time of the oldest backup that you intend to restore"
  • "At least one control file autobackup"
  • "A record of the DBID of the database"

Each one fails differently.

Data file backups. Without a backup of a data file, that file cannot be restored by RMAN (our reading). REPORT NEED BACKUP lists files that need backups under your policy.

Archived redo logs. A database backup taken while open is brought to a consistent point by applying redo. Oracle notes that in NOARCHIVELOG mode, "You can only back up a database in NOARCHIVELOG mode when the database is closed and in a consistent state." In ARCHIVELOG mode, a missing log in the sequence stops recovery at that point (our understanding). The documented BACKUP DATABASE PLUS ARCHIVELOG form backs up logs with the database.

Retention policy affects which logs are kept. The REPORT reference explains that "Any archived redo log files and level 1 incremental backups that are older than the oldest nonobsolete full backup are considered obsolete." It also notes: "A backup made with the KEEP UNTIL TIME clause is obsolete after the KEEP time passes, regardless of the configured retention policy settings." Before deleting obsolete backups, confirm the policy matches the oldest point your business may need to restore to (our recommendation); REPORT OBSOLETE lists candidates without deleting anything.

Control file autobackup. Covered below.

The DBID. The database identifier is a number unique to each database. Oracle says: "RMAN displays the DBID whenever you connect to a target database. You can also obtain it by inspecting saved RMAN log files, querying the catalog, or looking at the file names of control file autobackup." Record it somewhere that does not depend on the server (our recommendation).

How control file autobackup works

The RMAN CONFIGURE reference says: "By default, control file autobackup is turned on when the COMPATIBLE initialization parameter is set to 12.2 or higher." It adds: "Oracle recommends that you enable the control file autobackup feature."

When on, RMAN takes an autobackup:

  • "After every BACKUP or CREATE CATALOG command issued at the RMAN prompt."
  • "Whenever a BACKUP command within a RUN block is followed by a command that is not BACKUP."
  • "At the end of every RUN block if the last command in the block was BACKUP."
  • "After structural changes for databases in ARCHIVELOG mode."

It also captures the server parameter file (SPFILE) when the instance was started with one. Oracle qualifies this with "if the instance was started with a server parameter file". A text initialization file (PFILE), including a client-side PFILE, is not automatically covered by that promise. Protect it separately and record its location and the settings needed to rebuild the instance (our recommendation).

Where autobackups go

The reference explains: "If a fast recovery area is enabled, and if the format is the default '%F' , then RMAN creates the autobackup in the recovery area in a directory named autobackup . Otherwise, the default autobackup location is an operating system-specific location ( ?/dbs on UNIX, Linux, and Windows)."

The default %F and an explicitly configured disk format of %F are not equivalent for location selection. The reference says explicitly setting the disk format to %F uses the operating-system default location even when the fast recovery area is enabled; # default in SHOW identifies the default setting. On a physical server, either location can be local and lost with the machine. Record the actual backup-piece path and device from the job/alert log, any session format override, and the format and search settings needed during recovery (our recommendation).

Two further limits from the reference:

  • "Control file autobackups are never duplexed."
  • "You cannot configure RMAN to write the autobackup to multiple locations." It suggests ending a backup job with BACKUP CURRENT CONTROLFILE FORMAT to make another copy in a chosen place.

Structural-change autobackups have one more restriction: "This type of autobackup, unlike autobackups that occur in the preceding circumstances, is only to disk."

The %F name carries the DBID

The format specification says %F "Combines the DBID, day, month, year, and sequence into a unique and repeatable generated name" of the form c-IIIIIIIIII-YYYYMMDD-QQ, where the first part is the DBID "printed in decimal so that it can be easily associated with the target database." This is why an autobackup file name can recover a lost DBID (as Oracle notes). The CONFIGURE reference requires the autobackup format to include %F; any other substitution variable is an error. A directory or fixed prefix may change the destination or name, but %F must remain in the format.

Restoring from nothing: the order

The guide's procedures without a recovery catalog have two distinct NOMOUNT starts. This is a conceptual, untested sequence for an authorised isolated rehearsal, not a production runbook. A qualified DBA must choose the recoverable SCN or time, verify the required backups and logs, and adapt storage paths and media access before any restore.

  1. Set the DBID in RMAN from the off-host recovery record.
  2. Start the instance NOMOUNT before restoring the SPFILE. Oracle says to run STARTUP NOMOUNT; when the SPFILE is unavailable, RMAN attempts to start with a dummy server parameter file. Confirm the release-specific startup procedure and required environment.
  3. Make the backup media accessible, allocating the required device/channel as appropriate and setting the recorded control-file autobackup search format if it differs from the default. Then restore the SPFILE with RESTORE SPFILE FROM AUTOBACKUP.
  4. Restart NOMOUNT using the restored SPFILE, after the DBA has checked that its paths and settings are safe on the isolated host. This restart is separate from the initial dummy-parameter startup. Restore the control file from autobackup using the recorded DBID and search settings.
  5. Mount, restore and recover under the DBA's plan. Catalog needed backup pieces absent from the restored repository and map changed data-file paths as required. Recover to the explicitly selected supported endpoint, then open with RESETLOGS when the recovery procedure requires it. Do not assume that the last log found is enough to make all restored files consistent.

With a recovery catalog, the guide notes that "you can avoid recording and remembering the DBID", and that recovery with a backup control file "is identical to recovery with a current control file." A catalog on the same server as the database does not help when that server is lost (our reading).

Testing on a new host

Oracle describes restoring on a new host as "useful when you want to perform a test run of your disaster recovery procedures". It gives a warning: "Do not register a test database created in this way in the same recovery catalog as the source database. Because the DBID of the two databases is the same, the metadata for the test database can interfere with RMAN's ability to restore and recover the source database". For a lasting copy, it points to DUPLICATE, which "assigns a new DBID".

Repository reports and backup validation

SHOW, LIST, REPORT and RESTORE ... PREVIEW report repository information without restoring files. Validation is a separate operation: it reads backup blocks and can update corruption metadata and diagnostics. Run only authorised checks in the RMAN client connected to the intended target and catalog, and keep the output.

Configuration:

SHOW ALL;

Look for CONFIGURE CONTROLFILE AUTOBACKUP ON and the autobackup format and device. The reference says "The string # default in the output of the SHOW command indicates when RMAN is using the default format."

Control file backups and archived logs on record:

LIST BACKUP OF CONTROLFILE;
LIST BACKUP OF ARCHIVELOG ALL;
REPORT NEED BACKUP;

What a restore would use, without reading backups:

RESTORE DATABASE PREVIEW;

Oracle says PREVIEW "Reports—but does not restore—the backups and archived redo log files that RMAN could use", and that "RMAN queries the metadata and does not actually read the backup files." It also notes that offsite backups can show as available when "the media must be retrieved from storage before the backup can be restored", and that PREVIEW output "indicates whether backups are stored offsite."

Whether those backups can actually be read:

RESTORE DATABASE VALIDATE;
RESTORE ARCHIVELOG ALL VALIDATE;

The reference says with VALIDATE, "No files are restored" and "RMAN reads all blocks in the backup piece or image copy." It adds that "the database can be open with data files online." No restored output data files are created, but validation is not globally read-only: RMAN can update V$DATABASE_BLOCK_CORRUPTION and diagnostic records in the Automatic Diagnostic Repository, alert log or trace files. Reads consume I/O and may retrieve tape/offsite media, so authorise and schedule validation (our recommendation).

Logical checks. By default, Oracle notes, "RMAN does not check for logical corruption." Add CHECK LOGICAL to validation if you want logical checks as well.

These checks are partial. PREVIEW trusts the repository; VALIDATE proves backups can be read, not that the DBID record, the parameter file contents or the target server are ready (our reading).

Safe restore rehearsal

Run this on an authorised, isolated test server that cannot reach production storage or catalogs, with a non-production test database (our recommendation).

  1. Record the test database's DBID, configuration (SHOW ALL), a chosen recovery SCN/time and expected sample rows/checksums from a controlled synthetic fixture at that same point. Do not compare an older backup with changing live data.
  2. Back up with BACKUP DATABASE PLUS ARCHIVELOG and autobackup enabled. Ensure the chosen endpoint is covered. After the data, required log, control-file and SPFILE artifacts complete, verify that the exact required set is readable off-host before marking the protection job successful.
  3. Simulate loss: build a fresh test host with the same Oracle software and no database files.
  4. Restore the exact protected backup set following the order above, using the off-host DBID, media and path records, to the chosen supported SCN/time.
  5. Compare row counts and checksums with the baseline for that same recovery point, test the application, and record the endpoint and time each step took.
  6. Repeat once with the DBID deliberately unknown, recovering it from the autobackup file name, so the team knows how.

Diagnosing what you find

  • RMAN cannot find a control file autobackup: the DBID is wrong; the autobackup format is non-default and was not set; or the autobackup was on the lost server's local disk.
  • Recovery stops early: an archived log is missing from the sequence; logs were deleted before being backed up; or the needed log backup is offsite and not yet retrieved.
  • PREVIEW is fine but VALIDATE fails: a backup piece was moved or deleted outside RMAN; the media manager cannot reach the tape; or the piece is damaged.
  • Test restore disturbs production records: the test database was registered in the production catalog with the same DBID; or the test host could reach production storage.

Have a qualified Oracle DBA review the plan before any production use.

Worked example (illustrative)

The following is invented. An Oracle database runs on a physical Linux server with the fast recovery area on a local array. RMAN backups go to that area, and a nightly job copies the backup directory to a network share. Autobackup is on with the default format.

In this invented scenario, a rehearsal finds that the copy job runs before the current autobackup is written. The chosen endpoint is the recorded synthetic fixture at SCN 500000. Two archived logs required to reach it were deleted locally after a space alert, but verified copies survive in off-host backup pieces. The team retrieves those pieces and includes them in the recovery plan. If required redo had been missing everywhere, the team could not claim that endpoint was recoverable; a DBA would have to determine whether an earlier consistent endpoint was possible and record the resulting loss.

The team makes off-host protection success depend on completion and verified inclusion of the current data, required log, control-file and SPFILE artifacts, and records the DBID and recovery search settings. The hypothetical rehearsal then restores that exact protected set on the isolated server to the selected SCN 500000 recovery boundary and matches the fixture rows and checksums recorded for that boundary. Scheduled validation is an additional check, not a substitute for that restore. This outcome is illustrative, not a lab result from the authors.

Risks and limits

  • Oracle documentation evolves by release; confirm each command on your version.
  • Recovery catalogs, Data Guard and media managers add options not covered here.
  • No command in this guide was run in a lab. Test in an isolated environment first.

Sources

All accessed 14 November 2026. Oracle pages are served at the release 23 documentation path.

Related future topics

  • RMAN retention policies, obsolete backups and archived log deletion
  • Recovery catalogs: when a separate catalog server is worth it
  • Oracle parameter files and password files in a bare-metal rebuild

This article was originally published on .