Oracle Database / Advanced: secure and recoverable evolution / Lesson 16

Backup, recovery and restore evidence

Reason about recoverable points, RMAN metadata and complete application recovery without executing restore commands.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Distinguish restore, media recovery and logical export.
Specify a recovery proof with dependencies and business checks.

Define the loss and downtime budgets

Recovery point objective names how much committed business history may be lost; recovery time objective names how quickly a usable service must return. A nightly backup can be insufficient for a fifteen-minute loss budget without the appropriate recoverable change history. “The backup job succeeded” does not establish either objective. Identify the failure being addressed: lost files, accidental deletion, corrupted application data or a regional outage can need different recovery paths. Record who declares the target point and how shipments accepted after that point will be reconciled with carriers and external payment records.

Restore retrieves files; recovery advances them

RMAN restore retrieves data files and other supported files from backups. Media recovery applies incremental changes and redo to reach a consistent desired point. A physical backup is not the same thing as a Data Pump logical export, which reconstructs selected logical objects and has its own metadata, privilege and consistency boundaries. An online backup can require redo to become usable after restore. ARCHIVELOG operation and complete archived-log coverage are therefore central to many online recovery strategies. The course explains these dependencies and deliberately supplies no executable restore, shutdown or delete sequence.

A recovery chain must cover every needed interval

The synthetic ledger describes a base backup at position 100 and redo intervals covering successive ranges. To recover through position 160, the chain cannot skip the interval from 120 to 140 merely because a later log exists. Real Oracle recovery also tracks database identity, incarnation, thread and file checkpoints; this simplified ledger is only a teaching model. Do not substitute arithmetic on invented positions for RMAN’s validated metadata and an isolated restore rehearsal. Its purpose is to make the dependency visible before operational details obscure it.

text Illustrative technical example; logical results are reasoned, not engine-tested.

base_checkpoint: 100
required_redo: [100,120), [120,140), [140,160)
missing_redo: [120,140)
requested_target: 160
conclusion: target not proven recoverable

A gap invalidates this simplified coverage proof. These are model positions, not measured SCNs or RMAN output.

Protect the material outside data files

RMAN does not back up every dependency of an application. Network configuration, password files, software homes and external-table files need their own approved protection. Encrypted backups or encrypted data also require a tested key and wallet recovery path. A backup copied to independent storage is useful only if it remains readable and access survives the same failure scenario. The manifest below records evidence categories rather than credentials or actual locations. Treat retention as a recoverability policy over a complete dependency graph; deleting an apparently old piece can break a newer promised recovery window.

json Illustrative technical example; logical results are reasoned, not engine-tested.

{
  "database_identity_verified": true,
  "backup_piece_inventory": "reviewed lab manifest",
  "redo_coverage": "continuous to selected target",
  "key_recovery_evidence": "separately reviewed",
  "external_dependencies": ["network configuration", "application artifacts"],
  "restore_rehearsal": "required before claiming readiness"
}

A valid illustrative JSON checklist, not evidence that any real backup or restore has been verified.

Verify business service after technical recovery

A database opening is necessary but does not prove the application is ready. An isolated rehearsal should verify expected schema versions, representative shipment keys, accounting totals, referential integrity and a synthetic end-to-end booking. Measure elapsed phases, document unavailable external dependencies and test the runtime account’s approved connection path. A metadata preview can identify selected pieces but is weaker than reading and restoring them. Keep the latest successful rehearsal evidence with its exact scope and date. No backup validation, media access, database restore or recovery operation was performed while authoring this course.

Common errors and fixes

A successful backup is treated as a recovery guarantee

Why it happens: No isolated restore has exercised the required pieces, logs and dependencies.
How to fix it: Define and rehearse the specific target scenario with business verification.
Prevent it next time: Track restore evidence separately from backup job status.

Recovery cannot reach the requested point

Why it happens: A required redo interval or identity-compatible backup is unavailable.
How to fix it: Inventory the complete chain and select only a proven recoverable target.
Prevent it next time: Validate coverage against the promised recovery window before retention changes.

Restored encrypted files cannot be opened

Why it happens: The recovery environment lacks the required key material or access path.
How to fix it: Use the separately reviewed key-recovery procedure in an isolated rehearsal.
Prevent it next time: Include wallets, access ownership and dependency recovery in the plan.

Check your understanding

1. Does a logical export of shipment tables replace a complete physical recovery strategy?

Show worked solution

No. It protects a selected logical scope and has different consistency and reconstruction behavior. Map its role to the failure scenario while preserving physical recovery, redo and external dependencies where required. Verify the application after restoration rather than assuming the existence of exported rows proves service readiness.

2. Why is the ledger with [120,140) missing unable to prove recovery to 160?