| Lesson 5 | Backup Strategies |
| Objective | Describe the backup strategies available using the Backup Wizard. |
Oracle 26ai Backup Strategies with Enterprise Manager 24ai
Enterprise Manager 24ai Cloud Control provides an Oracle-suggested strategy and a customized strategy for scheduling RMAN backups. The suggested approach supplies a defined starting point suited to the configured backup environment. The customized approach lets the administrator select the protected scope and backup operation more explicitly. Both need a recovery plan: choosing a wizard option does not establish that the resulting backups meet the organization's requirements.
For Oracle AI Database 26ai, compare strategies by the recovery they support, the resources they consume, and the work required to maintain them. The previous lesson established scheduling prerequisites. This lesson explains the choices to make before reviewing and submitting a backup job. The following lesson applies those choices through the backup scheduling workflow.
The historical Oracle8i desktop Backup Wizard is no longer a reliable guide to current screens. In Cloud Control, Oracle documents the database-home path Availability > Backup & Recovery > Schedule Backup. Available choices depend on the installed release update, database plug-in, target type, and configured storage. Confirm support for the particular deployment and use the wizard's Help to interpret its current options.
Start with the required recovery outcome
A backup strategy answers several connected questions: what needs protection, how frequently to protect it, where to store the results, how much history to retain, and how to recover after a failure. A schedule answers when a chosen operation runs. These decisions belong together, but selecting a daily start time does not resolve the others.
The recovery point objective, or RPO, sets the acceptable loss of recent work. The recovery time objective, or RTO, sets the acceptable interruption before service returns. A database that can lose a day's changes has different protection needs from one that can lose only a few minutes. Likewise, a recovery procedure acceptable for a small training database may be too slow for a large production system.
Record the intended recovery window, expected data growth, change rate, storage capacity, and available backup period. Identify the people who will respond to missed runs and perform recovery. Use measured behavior to compare alternatives. A backup that finishes quickly can still require slow media retrieval, a long restore, or extensive redo application.
Compare the two strategy choices
| Decision | Oracle-suggested | Customized |
|---|---|---|
| Starting point | A strategy appropriate to the configured backup environment. | An explicitly selected scope and operation. |
| Typical purpose | Adopt a supported baseline after reviewing its recovery behavior. | Implement requirements that need different scope, backup patterns, or storage choices. |
| Administrator review | Check generated work, storage, redo coverage, retained history, and timing. | Check each selected option and its effect on the recovery chain. |
| Acceptance evidence | Successful representative runs and tested recovery. | Successful representative runs and tested recovery. |
Neither choice transfers responsibility for recovery to the wizard. The useful distinction is how much of the operation is supplied as a starting point and how much is selected individually. Document the final script and configuration so another administrator can explain the protection actually provided.
Understand the Oracle-suggested strategy
Enterprise Manager's current backup_database documentation describes suggested backups for disk and Recovery Appliance destinations. Do not interpret the suggested choice as a universal nightly full backup. Its behavior must be evaluated against the selected destination and local configuration.
A conventional disk incremental-update approach begins with level 0 datafile image copies. Subsequent level 1 backups provide changed blocks that can be applied to those copies. Rolling the copies forward avoids repeatedly creating a complete new copy. The strategy also needs the redo and retained history necessary for the intended recovery points.
Consider a copy as a recoverable database image at a particular checkpoint, rather than as an indefinitely reusable record of every earlier state. Updating it moves that checkpoint forward. Before accepting a merge schedule, identify which older recovery points must remain available and how the retained copies, incrementals, and logs support them. Do not assume that a recent copy alone satisfies a long recovery window.
Zero Data Loss Recovery Appliance provides a different incremental-forever environment. It receives an initial level 0 and subsequent incremental backups and maintains virtual full backups through its own processing. This requires a configured protected database and appliance protection arrangement. It is not the same operation as merging incrementals into a local disk image copy. Follow the appliance's prescribed backup and redo procedures.
A suggested strategy is useful when its design fits the agreed plan and the team can operate it consistently. Review the first run separately from recurring runs: initialization may require more space and time than ongoing protection. Confirm that new files, changes in workload, and missed executions are included in later operational reviews.
Define a customized strategy
A customized strategy makes the backup selection more explicit. Decide which database material to protect, choose the applicable full or incremental operation, and review destination, archived-log handling, encryption, and timing. Then inspect the generated RMAN work. A familiar checkbox label is insufficient evidence that every required file or recovery dependency is included.
For example, a team might choose a periodic level 0 database backup with daily level 1 backups and more frequent archived-log protection. Another team might need an independent full backup for a specific operational purpose. The correct choice depends on the intended recovery, available capacity, and measured duration. These examples describe patterns to evaluate, not production schedules to adopt without testing.
Enterprise Manager also documents EMCLI backup submission and a Fleet Schedule Backup REST endpoint. These interfaces have their own parameter sets and supported combinations. The REST endpoint documents Oracle-suggested, custom, and control-file choices with OCI or Recovery Appliance destinations. Do not assume that every console or EMCLI option is available through that endpoint.
Submitting work to several database targets is a management operation. It does not create extra backup copies for each database or prove that all targets share compatible configuration. Each target still needs a reviewed scope, execution environment, storage destination, and recovery procedure.
Select the protected scope
A whole multitenant container database backup and a selected pluggable database backup protect different material. Identify the CDB, root, seed, and PDBs involved in the recovery plan. A selected-PDB job is useful for a specific requirement, but it must not be described as whole-CDB protection.
Tablespace and datafile selections narrow the backup operation further. They can support targeted protection where the overall recovery plan covers the remaining database material. They also increase the need to track dependencies. Record what each job excludes and how the excluded material is protected, rather than relying on a collection of unnamed partial backups.
Archived redo logs protect changes needed after a datafile backup checkpoint. Their backup frequency may need to be higher than the datafile backup frequency. Plan redo protection at the appropriate CDB-root scope, particularly when datafile jobs focus on selected PDBs. A small PDB backup does not establish that all logs required for its recovery remain available.
Protect the control file and server parameter file through reviewed RMAN settings and operations. If a recovery catalog is used, protect it independently. Enterprise Manager job history supports monitoring; it does not replace RMAN metadata or actual backup storage. Other host configuration, required encryption keys, and recovery documentation need their own protection arrangements.
Account for ARCHIVELOG and NOARCHIVELOG mode
In ARCHIVELOG mode, RMAN can back up an open database while required archived redo supports recovery of the resulting datafile backups. Review the log inclusion and retention settings explicitly. A database backup operation and an archived-log backup operation are related parts of the plan, rather than interchangeable protections.
In NOARCHIVELOG mode, an applicable whole-database backup requires a consistent shutdown and a mounted database. This creates an availability requirement that must be planned. Do not assume that every current wizard operation automatically closes and reopens the database as the old desktop workflow described.
Database mode is therefore a strategy constraint, not an incidental scheduling preference. Before selecting an online or partial backup pattern, establish how the database state and available redo support the intended recovery. Resolve that question before setting recurrence or accepting a successful job as complete protection.
Distinguish full backups from incremental bases
A full datafile backup and a level 0 incremental backup can contain comparable datafile content, but they have different roles. The level 0 establishes the base for an incremental strategy. A full backup does not become that base, and RMAN cannot convert it into a level 0 after creation.
The following commands illustrate the distinction. They create backups when executed; this lesson does not execute them. The target connection, device configuration, credentials, available space, and recovery scope must be reviewed before any real use.
BACKUP DATABASE;
BACKUP INCREMENTAL LEVEL 0 DATABASE;Do not select between these operations by repeating the legacy claim that one backs up blocks that have never been used. RMAN's handling of unused blocks depends on backup format and conditions. The important strategy question is whether the output is intended to serve as an incremental base.
Compare differential and cumulative level 1 backups
A differential level 1 backup records changes since the most recent applicable level 1 or level 0 backup. A cumulative level 1 records changes since the level 0. Oracle 26ai's ordinary incremental strategy uses levels 0 and 1; the legacy lesson's level 2 examples should not guide current configuration.
BACKUP INCREMENTAL LEVEL 1 DATABASE;
BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;Imagine a Sunday level 0 followed by daily differential level 1 backups. Tuesday's backup normally covers changes since Monday's incremental. Recovering using this pattern can require successive incrementals after the base. Smaller daily outputs can reduce backup storage and transfer, but the recovery process depends on an adequate sequence of retained material.
With cumulative level 1 backups, Tuesday's backup includes changes since Sunday, including the changes already captured on Monday. Later cumulative backups can grow as changes accumulate. A suitable later cumulative can reduce the incremental application chain compared with using every daily differential. Redo is still needed to reach the required point after the backup checkpoint.
Compare both patterns using the actual rate of change and recovery tests. A workload with small daily changes may benefit from differential backups, while a tighter recovery-time requirement may justify larger cumulative outputs. Changing the pattern also changes capacity estimates and the material that must remain accessible during recovery.
Choose backup format and destination separately
Backup sets and image copies describe output format; full and incremental describe the backup's role and content. A backup set is an RMAN-managed collection stored in backup pieces. An image copy is a copy of a supported file that RMAN can use in recovery. Level 1 incrementals are backup sets that can provide changed blocks for updating datafile copies.
For disk output, review the configured filesystem, ASM destination, or fast recovery area. Account for retained generations, initialization space, concurrent work, and future growth. Keeping all protection on the same failure-prone host or storage system can leave a serious recovery gap even when the backup job consistently succeeds.
RMAN uses DISK and SBT device types. Tape and supported cloud arrangements require their appropriate media or cloud integration. An object-storage address is not a substitute for a disk directory. Identify the restore libraries, service access, credentials, network path, and key access that would be needed after losing the original host.
Compression, channel parallelism, and encryption affect operational cost and recovery dependencies. Review them with the chosen destination and applicable feature requirements. A faster backup can increase production contention; an encrypted backup can be unusable if the recovery team cannot obtain the required keys. Include these consequences in strategy acceptance.
Coordinate retention, logs, and recurring jobs
Retention policy expresses the history required by the recovery plan. Job frequency expresses how often protection is attempted. Neither guarantees that a particular backup is usable. Review how the retained datafile backups, incrementals, and archived logs work together for the intended window.
Skip and deletion options deserve separate review because they can alter what remains available. Do not automatically add archived-log deletion or obsolete-backup cleanup to a new strategy. Establish the required recovery and standby dependencies first, then evaluate any separately approved cleanup procedure.
Assign meaningful job names and owners, and compare expected duration with repeat intervals and maintenance activity. Monitor both failed executions and expected executions that never start. Reassess capacity and timing when the database grows or the change rate increases. A strategy that worked last quarter may need adjustment even if its definition is unchanged.
Accept the strategy through recovery evidence
After a representative backup run, inspect the full RMAN output and confirm that the intended material is recorded and accessible. Review warnings, elapsed time, destination use, and any omitted scope. Job completion is one piece of evidence, not a substitute for understanding the resulting recovery chain.
Use appropriate validation to examine the files and backup material needed for recovery. A restore-validation operation can check selected backups without restoring datafiles. A controlled restore and recovery exercise tests additional dependencies, including retrieval, keys, configuration, redo application, and elapsed time. Carry out that rehearsal in an isolated environment with clearly identified targets.
Record the recovered point, recovery duration, and missing dependencies. Compare the result with the agreed RPO and RTO, then revise the strategy where necessary. This gives the choice between suggested and customized backups an operational basis that a wizard screenshot or green completion indicator cannot provide.
The next lesson configures and schedules a backup using the current Cloud Control workflow. Bring the selected strategy, scope, storage configuration, redo plan, retention requirements, and test evidence to that review.
Oracle documentation
- Enterprise Manager 24ai: backup_database, suggested and customized strategy parameters.
- Oracle 26ai: Backing Up the Database, Cloud Control entry points and incremental operations.
- Oracle 26ai: BACKUP reference, command semantics and output options.
- Configuring the RMAN Environment, device and retention configuration.
- Recovery Appliance Incremental-Forever Strategy, appliance-specific protection and virtual full backups.
- Enterprise Manager Fleet Schedule Backup REST API, endpoint-specific options.
- Validating Database Files and Backups, validation and recovery-readiness checks.