Lesson 1

In a perfect world, databases would be available 24 hours a day, 7 days a week, 365 days a year. In the real world, that's not the case. That's why a good database administrator has to be aware of what can, and eventually will, go wrong with a database, including situations entirely beyond their control. This module covers the considerations a good DBA has to evaluate when building, or reassessing, a backup and recovery plan.

Some of what goes wrong is entirely predictable and preventable: a disk that finally fails after years of warning signs, a patch applied without a rollback plan. Some of it isn't: a data center loses power during a storm, a junior developer runs an UPDATE with no WHERE clause against production on a Friday afternoon. A backup and recovery strategy has to account for both categories, since a plan that only covers the predictable failures is really only half a plan.

By the end of this module, you'll be familiar with:

1. DBA responsibilities
2. Business considerations
3. Operational considerations
4. Technical considerations
5. The components of a disaster recovery plan
6. The importance of testing a backup and recovery strategy

There will come a time when a database crashes and a job is on the line. No one can plan for every possible situation, but the better prepared a DBA is going in, the more likely they are to come out the other side of a crisis intact. This lesson starts with the most foundational decision underneath any backup strategy at all: physical backups versus logical backups.

Oracle AI Database's own documentation draws this same line: database backups are either physical or logical, and the choice between them depends on the specific database's requirements, the intended use of the backup, the flexibility needed during recovery, and the database's own size and complexity.

Physical backups are copies of the database's actual physical files, datafiles, control files, and archived redo logs, made with RMAN (Recovery Manager), Oracle's dedicated backup and recovery tool, or with operating system utilities directly. A physical backup is a byte-for-byte copy of what it backs up, and can be taken while the database is online (often still called a hot backup) or after a clean shutdown (a cold backup); Oracle's more precise terms for this same distinction are inconsistent and consistent backups, respectively, both terms still worth knowing since both show up in practice.

• Use case: Physical backups are the foundation of disaster recovery. They're the right tool when the goal is restoring an entire database, or performing a point-in-time recovery.
• Advantages: Fast to restore, since restoring largely means copying files back to where they belong. Comprehensive by nature, since the entire database is included, nothing gets missed.
• Disadvantages: Large, since the whole database is captured, and less flexible than a logical backup, since a physical backup doesn't support recovering a single object on its own.

That speed advantage is worth being concrete about, since it's the reason physical backups anchor most real disaster recovery plans. Restoring a physical backup means putting files back where the database expects to find them and letting the database apply whatever redo has accumulated since; it's fundamentally a copy operation, closer to the underlying hardware's own speed than to anything SQL-level. A logical restore, by contrast, has to actually execute the work of rebuilding every table, every index, every constraint, one SQL statement at a time, which is a meaningfully different, and slower, kind of operation regardless of how fast the hardware underneath it is.

RMAN itself is a client that connects to the target database (and optionally a separate recovery catalog database) and issues backup and recovery commands against it, and Oracle specifically recommends configuring a fast recovery area, a database-managed location that centralizes control files, redo logs, and backups in one place, to support this. Within RMAN, a physical backup takes one of two forms: an image copy, a straightforward bit-for-bit duplicate of a single file, or a backup set, RMAN's own proprietary format capable of combining multiple files together and of writing to sequential media like tape, something an image copy can't do on its own.

Whether a hot, inconsistent backup is even possible in the first place depends on one setting made well before backup time: whether the database is running in ARCHIVELOG mode. A database in ARCHIVELOG mode preserves its redo logs after they're written, rather than letting the database overwrite them, which is what makes it possible to take a backup while the database stays open and still recover it to a consistent state afterward, replaying the preserved redo to catch up whatever changed while the backup was running. A database in NOARCHIVELOG mode has no such record to replay, which is exactly why a consistent, cold backup, taken only after a clean shutdown, is the only fully valid backup option available to it. This single setting is one of the first things worth checking when evaluating, or inheriting, an existing backup strategy, since it determines which of the options above are even on the table.

Logical backups contain logical data, tables, stored procedures, and other schema objects, extracted with a tool like Oracle Data Pump (expdp and impdp) or the older exp/imp utilities, which Data Pump has largely superseded. The output is either a set of SQL statements or Data Pump's own binary dump file format.

• Use case: Logical backups are the right tool for migrating data between databases or database versions, or for recovering a specific object rather than an entire database.
• Advantages: Genuine flexibility to recover individual objects, and portability across different database structures or versions. Generally smaller than an equivalent physical backup.
• Disadvantages: Slower to restore, since the data has to be reinserted through SQL rather than simply copied back into place. Not a substitute for a real disaster recovery strategy, since a logical backup contains no system-level files at all.

That portability is worth being specific about too, since it's what physical backups categorically cannot offer. A Data Pump export taken from one Oracle version can generally be imported into a newer one, and the reverse often works within supported ranges as well, something a physical backup can't do at all: a physical backup is tied to the exact structure of the database it came from, right down to its physical file layout, and restoring it means restoring into an environment built to match. That's precisely why logical backups fit migration and cross-version work so naturally, and precisely why they're the wrong tool when the actual goal is getting an entire, unchanged database back after a catastrophic failure.

A handful of factors tend to decide which approach, or combination, actually fits a given situation:

1. Recovery requirements. Complete disaster recovery calls for physical backups; recovering a specific object or migrating data calls for logical ones.
2. Downtime tolerance. Physical backups can run against a live, online database. Data Pump exports can generally do the same for most workloads, though particularly demanding concurrent activity may still call for a quieter window to guarantee consistency.
3. Database size. Physical backups scale more practically for large databases; a full logical export and import of a genuinely large database can become impractical in both time and storage.
4. Flexibility and portability. Logical backups win here, supporting partial recovery and portability across architectures and versions that a physical backup can't offer.
5. Backup window. Physical backups integrate with media management solutions for tape-based backup, relevant when the available backup window is tight.
6. Resource utilization. Logical backups tend to demand more CPU and I/O for the export and import process itself.
7. Data specificity. Cloning a specific subset of data for development or testing is usually a job for a logical backup.

A concrete scenario makes these factors easier to weigh against each other than the list does on its own. Consider a 40-terabyte production order-management database, running around the clock, where the business has decided it can tolerate at most one hour of data loss in a genuine disaster. A full logical export of a database that size would take far longer than the backup window actually available, and restoring it row by row through SQL would take even longer, ruling logical backups out as the primary strategy immediately. RMAN running in ARCHIVELOG mode, incremental physical backups layered on top of periodic full ones, is the only realistic way to meet that one-hour recovery objective at this scale. Logical backups still have a role here, just a narrower one: a nightly Data Pump export of a handful of specific schemas, kept around specifically so a single accidentally-dropped table can be restored in minutes without touching RMAN or reaching for a full database restore. Neither approach replaces the other; each is doing the specific job it's actually suited for.

In practice, this is rarely an either-or decision. Most real backup strategies use both: physical backups for genuine disaster recovery, logical backups for portability and object-level recovery, sized and scheduled according to the organization's actual recovery objectives and constraints.

One distinction worth making explicitly, since it trips up plenty of people new to this material: neither physical nor logical backups are the same thing as Oracle Data Guard. Backup and recovery, physical or logical, is about capturing a point-in-time copy of a database that can be restored later if something goes wrong. Data Guard is a different discipline entirely: it maintains one or more standby copies of a database that stay continuously synchronized with the primary, ready to take over with a failover if the primary becomes unavailable. A backup answers "how do we get back to a known-good state after something breaks"; Data Guard answers "how do we avoid meaningful downtime in the first place when something breaks."

The distinction matters practically, not just semantically. A well-maintained Data Guard standby can fail over in minutes with effectively no data loss, but it protects against exactly one category of problem: the primary database, or the site it runs in, becoming unavailable. It does nothing at all to protect against a user error, since a bad UPDATE or a dropped table replicates to the standby just as faithfully as every legitimate change does; by the time anyone notices the mistake, the standby has usually already made the same mistake too. A physical or logical backup, taken before that error occurred, is what actually recovers from it. A mature disaster recovery strategy typically uses both, for two genuinely different purposes, rather than treating one as a substitute for the other. This course focuses on backup and recovery specifically, but knowing where that discipline's boundary actually sits, and what it doesn't cover, matters just as much as knowing what it does.

What's Ahead

Physical and logical backups are the foundation this whole module builds on, but they're only the starting point. Later lessons in this course cover Oracle Flashback Technology (rewinding a table, or an entire database, to an earlier point in time without a full restore), the specific mechanics of data repair after a media failure or a user error, and the fuller set of business, operational, and technical considerations that turn a backup strategy into an actual disaster recovery plan.

Each of those upcoming topics builds directly on the distinction covered here. Flashback Technology, for instance, occupies a middle ground between the two backup types this lesson introduced: it can undo a user error, dropping a table, an erroneous mass update, far faster than a physical restore would, without ever touching a backup file at all, but it depends entirely on undo and redo information the database itself already retains, not on any backup strategy directly. Understanding why Flashback works the way it does, and where its limits sit, only makes sense once the more fundamental physical-versus-logical distinction covered in this lesson is solid.

The business, operational, and technical considerations still ahead in this module are really just this same core question, asked from different angles: how much data can the organization afford to lose, how much downtime can it tolerate, what does recovering actually cost in time and infrastructure, and who is actually accountable when the crisis this lesson opened with finally arrives. The next lesson looks specifically at the first of those questions, the responsibilities of a database administrator, and what a DBA is actually on the hook for when a backup and recovery plan gets put to the test.

A few points from this lesson worth carrying forward:

• Physical backups, made with RMAN or operating system utilities, are byte-for-byte copies of a database's actual files, fast to restore and comprehensive, but large and incapable of restoring a single object on its own.
• Logical backups, made with Data Pump, capture schema objects as SQL or a binary dump, offering genuine flexibility and portability at the cost of restore speed and any real disaster recovery guarantee.
• Whether a hot, online backup is even possible in the first place depends on ARCHIVELOG mode; without it, a consistent backup after a clean shutdown is the only fully valid option.
• Oracle Data Guard solves a different problem entirely, continuous standby availability rather than point-in-time recovery, and isn't a substitute for a real backup strategy or the reverse.
• Most real-world strategies use physical and logical backups together, each covering the specific scenario it's actually suited for, rather than treating the choice as strictly either-or.