| Lesson 2 | Introducing basic database backup concepts |
| Objective | Identify the Available Classes of Database Backup. |
Available Classes of Database Backup in Oracle
Oracle backup strategies are usually described in “classes” because different backup methods solve different problems. Some backups are designed for disaster recovery after a storage failure, while others are designed for object-level recovery, migrations, refreshes, or compliance retention. In modern Oracle environments (including Oracle 23ai and OCI services), the same fundamental classes still exist—however, the preferred tooling and operational approach has shifted heavily toward RMAN-based physical backups, Fast Recovery Area (FRA) management, and cloud-managed automation.
Backup classes, at a glance
-
Physical backups (database files and recovery files)
- Datafiles, control files, server parameter file (SPFILE), archived redo logs, and (when needed) online redo logs.
- Typically produced and managed with RMAN (backupsets or image copies), sometimes integrated with snapshot or storage tooling.
-
Logical backups (schema objects and table data)
- Exports of metadata and rows for selected objects or full schemas.
- Historically done with EXP/IMP; modern Oracle uses Data Pump (
expdp/impdp). - Best for migrations, selective restores, or moving data between environments—not for fastest media recovery.
-
Online (hot) vs. offline (cold) backups
- Online: database remains open; requires ARCHIVELOG and proper redo handling.
- Offline: database is shut down; produces a consistent copy but requires downtime.
-
Full vs. incremental backups
- Full: baseline copy of the database (or a large portion).
- Incremental: captures changes since a baseline; commonly used with RMAN to reduce backup window and storage.
Physical versus logical
- physical and
- logical.
A physical backup is a byte-for-byte copy of the database’s physical files (or an RMAN-managed backup representation of them). Historically this could be done purely with operating system copy commands, which is why you will still see the term operating system backup (O/S backup) in older Oracle material.
A logical backup is created by extracting object definitions and row data into an export file.
Historically, the course material references the legacy EXP utility (the source of the exp legacy flag). In modern Oracle, Data Pump is the standard logical-backup utility:
expdp creates exports and impdp imports them.
The images below illustrate the concept of physical versus logical backups. They remain useful as a mental model even though the preferred tooling has changed.
Why physical backups dominate disaster recovery
-
Physical backup:
A complete physical backup strategy includes the control file, server parameter file (SPFILE), datafiles, and archived redo logs.
In the case of media failure[1], physical backups are the primary mechanism for restoring the database
and rolling forward to a desired recovery point using archived redo and (if required) online redo.
In modern practice, RMAN is the preferred tool because it validates backups, tracks backup metadata, supports incremental strategies, and integrates tightly with Oracle recovery features.
-
Logical backup:
Logical backups are best viewed as a supplement to a recovery strategy:
they are excellent for object-level recovery (a dropped table, a schema refresh, a migration, test data movement),
but they are usually slower and less complete than physical recovery for large databases.
Historical note: the older EXP utility could be time-consuming on large systems. Modern Data Pump is faster and more flexible, but it still does not replace RMAN for full media recovery.
Historical classes of Oracle backup
-
Export/Import (legacy):
“Logical” backups that extract object definitions and data to a file.
- Then: EXP/IMP utilities (legacy).
- Now: Data Pump (
expdp/impdp).
- Cold (offline) backups: Shut down the database and back up all required files in a consistent state.
- Hot (online) backups: Back up while the database is open in ARCHIVELOG mode, relying on redo to ensure recoverability. (Modern Oracle relies on RMAN to orchestrate this safely, rather than manual tablespace “backup mode” routines.)
- RMAN backups: RMAN can perform offline or online backups, validate backups, manage retention, and drive recovery. In modern Oracle environments, RMAN is the default for production-grade physical backup and recovery.
The practical takeaway is: use physical backups (RMAN) for recoverability, and use logical backups (Data Pump) as a complementary tool for migrations and object-level recovery. A strong strategy typically uses both.
Modern paradigm in Oracle 23ai and OCI
- RMAN + Fast Recovery Area (FRA): FRA centralizes recovery-related files (archived redo, flashback logs, backups) and supports policy-driven retention and cleanup. You size and monitor FRA rather than treating archived redo as an unmanaged file system.
- Incremental strategies: Incremental backups reduce daily backup volume and backup window. Many organizations use periodic full backups with frequent incrementals, plus archived redo for point-in-time recovery.
- OCI managed services: In Autonomous Database, backup and many recovery operations are service-managed. In co-managed OCI database services (Base Database Service / Exadata Database Service), DBAs still design RMAN policies, retention, and monitoring, but storage and infrastructure are typically more standardized.
- Data Pump for portability: Use Data Pump when you need schema-level portability, environment refreshes, selective restores, and migrations across systems.
What is mirroring?
When multiplexing files, Oracle writes the same content to multiple members (for example, multiple members of an online redo log group). This reduces single points of failure for critical redo information.