Schedule Database Backups with Enterprise Manager 24ai

Prepare the target and the recovery requirement

Begin with the database you intend to protect. Check its target identity and host, especially when development and production systems have similar names. A familiar display name alone is not sufficient evidence that you selected the correct environment. Confirm that the database is discovered and that the required management agent can communicate with Enterprise Manager.

Write down the recovery requirement before choosing a time. How much recent data could the business afford to lose? How quickly must service return? These questions establish the recovery point objective and recovery time objective. A convenient overnight window is not automatically an adequate protection policy. The schedule must also provide the archived redo and other recovery material needed between database backups.

Check that the destination has enough capacity for the expected backups and retained recovery history. Review any competing batch jobs, maintenance, and storage activity. Assign an owner who will investigate missed or failed executions. A recurring job with nobody responsible for its results can fail repeatedly while still looking like a completed configuration task.

Review the backup configuration

Configuration answers where and how RMAN writes the backup; scheduling answers when Enterprise Manager requests the work. Keep these decisions separate during review. A correct schedule cannot repair an inaccessible destination, an unsuitable retention policy, or a missing credential.

• Destination: identify the disk location or configured media-management destination. A disk path refers to storage accessible to the database backup process, not a folder on the computer displaying the browser.
• Channels: review the device type and parallelism appropriate to the destination. Additional channels can increase resource demand; choose them from measured requirements rather than assuming more is always faster.
• Retention: check the configured recovery window or redundancy policy. Retention determines which backups are needed under the policy; it does not itself create a recurring schedule.
• Supporting files: review protection for the control file and server parameter file, along with any encryption keys needed during recovery.
• Recovery catalog: if the environment uses one, verify the intended catalog connection. Do not assume every target uses a catalog simply because another database does.

For an authorized administrator examining the same target in RMAN, the following command displays persistent configuration. It is an illustrative inspection command, not output from a database used in this lesson:

SHOW ALL;

Compare those settings with the options shown by the wizard and any overrides in the proposed backup. Oracle documents these settings in Configuring the RMAN Environment. Record the chosen destination and policy with the job so that another administrator can understand the intended protection.

Check credentials without embedding passwords

Distinguish the account used to sign in to Enterprise Manager from the database and host credentials used for the backup operation. Successful console login does not prove that the submitted work can connect to the target or access its storage. Use approved named credentials and the required backup privileges for your installation.

Before relying on unattended execution, confirm that the job owner can use the selected credentials and that the account will remain valid. Review credential changes as part of operations: rotating a password or changing a host account can affect an existing schedule. Keep passwords out of lesson notes, job descriptions, scripts, and screenshots. The historical sample login from the old desktop-console exercise is not a current setup instruction.

Open Schedule Backup and select the scope

Oracle's database backup guide documents this route from the database home page: Availability > Backup & Recovery > Schedule Backup. Provide the required database credentials if prompted. Review the displayed target again before continuing. The guide's Cloud Control backup procedures also describe the separate choices for a container root and pluggable databases.

For a multitenant database, distinguish protection of the whole container database from a root-only backup or a selection of PDBs. Choosing the root does not mean all application PDBs were included. Write the selected scope explicitly in the review notes. If the intention is to protect the complete application environment, check whether it also depends on data or files outside that database.

Next choose the strategy. An Oracle-suggested strategy applies the supported approach for the selected destination. A customized strategy lets you choose the scope and backup options for your own plan. Use the strategy established in the preceding lesson rather than changing it just because another button appears more convenient. Consult the installed help for the exact choices available to this target.

Choose the backup type deliberately

A full backup and an incremental level 0 backup have different roles. Although both protect the data needed for their scope, a full backup does not serve as the parent of a level 1 incremental strategy. If the plan depends on level 1 backups, establish the appropriate level 0 baseline. Oracle explains the distinction in RMAN Backup Concepts.

Review archived redo protection as part of the plan. Online database backup requires the appropriate ARCHIVELOG configuration, and recovery needs the required redo as well as datafile backups. Do not select log deletion or obsolete-backup deletion merely to make the destination smaller. Confirm that any cleanup is consistent with recovery requirements and other consumers, such as standby databases.

Define when the backup runs

Choose a single execution when testing the initial configuration or taking a backup for a particular event. Choose recurrence when implementing an ongoing policy. Submitting a request now and running its backup now are separate decisions: a submitted request can be scheduled to execute later. Read the final schedule rather than interpreting submission as immediate execution.

For each schedule, record the start date, start time, time zone, repetition rule, and end condition. If the job repeats indefinitely, identify who will retire or revise it when the database changes. If it stops on a specified date, include that date in operational review so that protection does not silently end.

Review and submit the request

Choose a descriptive job name that identifies its target, purpose, and strategy. A name such as PETS_NIGHTLY_BACKUP is easier to recognize than a generic sequence number. Put ownership and the reason for the schedule in the description; avoid putting credentials or confidential connection details there.

On the final review page, compare the request with your written plan. Check target identity, database scope, backup type, destination, credential references, archive-log handling, and schedule. Inspect the generated RMAN work if the interface exposes it. Resolve unexpected options before submission, especially anything that deletes recovery material.

After submitting, retain the execution or procedure identifier and its scheduled time. Use the appropriate activity or execution detail view for the submitted operation. Interface labels vary by release and job type, so the old desktop console's Active and History tabs are not a universal navigation recipe. The useful evidence is the actual execution record and its detailed output.

A guided PETS backup exercise

The following is a practice scenario, not a record of a backup performed on a real system. Assume PETS is an authorized training database target with working credentials, adequate disk space, and an approved online backup configuration. Use a one-time customized backup to learn the submission and verification sequence before creating an unattended schedule.

1. Identify PETS. Open its database home page and confirm the host and environment. If the displayed target is different from the exercise target, stop and select the intended database.
2. Open Schedule Backup. Follow the database's Availability and Backup & Recovery navigation, then complete any required credential selection.
3. Choose the scope. For a whole-database exercise, verify the whole CDB scope when applicable. Do not substitute Container Database Root or a single PDB.
4. Select the customized options. For this independent full-backup exercise, choose the supported full backup option and review archived redo inclusion. Use level 0 instead only if you are deliberately establishing an incremental strategy.
5. Review the destination. Confirm the configured disk location and the expected resource use. Ensure the review shows the intended backup settings rather than another target's assumptions.
6. Choose a one-time execution. Use an approved time and explicitly review its time zone. Immediate execution is appropriate only when the training environment is ready for the work.
7. Review and submit. Give the request a useful name, inspect its summary, and retain the returned identifier.
8. Follow the execution. Read the detailed result, check the backup history, and record the outcome. Treat the exercise as incomplete if you only have a submission acknowledgement.

After a successful practice run, design the recurring job as a separate decision. Recheck whether the exercise's full-backup choice is appropriate for the ongoing strategy. Avoid leaving both a test schedule and a production schedule active by accident. A repeated test can consume storage without improving the intended recovery plan.

Verify completion and investigate failures

Verification has several layers. First establish that the request was accepted. Next establish that the intended execution started and completed. Then inspect the RMAN messages and backup records for the expected database, scope, and destination. Finally, establish that the recovery process can use the resulting material. Each layer answers a different question.

If the request never starts, investigate scheduling, agent availability, and the execution framework. If it starts but cannot connect, examine the credential and privilege errors. If backup output cannot be written, investigate destination availability, permissions, capacity, and any media-management configuration. Use the first meaningful error and the surrounding output to guide diagnosis instead of repeatedly resubmitting the same request.

After correcting a failure, check whether the original request is still pending before submitting another. Record what changed and which execution proves the correction. For recurring protection, verify the next occurrence as well: a successful manual retry does not by itself prove that unattended scheduling has recovered.

Use RMAN validation and planned recovery exercises to build stronger evidence. Oracle's validation documentation distinguishes checks of database files from checks of backups used for restore. A successful backup job is not a timed recovery rehearsal. Practice recovery in an isolated environment, including access to required keys and supporting files, and compare the measured result with the recovery time objective.

Automation and Enterprise Manager protection

For repeatable administration, Enterprise Manager also exposes the backup_database EM CLI verb. Its -customBackup and -suggestedBackup forms support backup scheduling; the documented schedule fields include start time, time zone, frequency, and repetition. Use the 24ai command reference for the exact syntax and target-specific prerequisites. Automation still requires the same configuration review and result verification as the GUI.

Protect Enterprise Manager itself separately. Chapter 27 of the Enterprise Manager 24ai Advanced Installation and Configuration Guide discusses the management repository, Oracle Management Service, management agents, and Software Library. A scheduled backup of PETS does not protect all those components. Include their recovery procedures in the operational plan so that loss of the management infrastructure does not leave the team without its documented recovery process.

Completion checklist

Keep a short operational record for the schedule. For example, the PETS record could identify the approved database target, backup destination, responsible team, planned start time and zone, expected completion window, and the location of the recovery runbook. Add the identifier of the first successful execution and the date of the latest recovery exercise. These are suggested record fields, not additional Enterprise Manager screen labels.

Review this record when the database grows or its workload changes. A job that once finished comfortably before business hours may eventually extend into peak activity. Compare recent durations and failures with the original expectations, then revise the schedule or configuration through the normal change process. Preserve enough execution history to explain why the adjustment was made.

Include a handover check when ownership changes. The new operator should be able to find the next scheduled execution, locate its detailed output, and identify the escalation contact. This small exercise tests whether the backup process is maintainable beyond the administrator who originally clicked through the wizard.

Before considering the schedule operational, confirm that another administrator could answer these questions from the saved job details and runbook:

• Which exact database and containers are protected, and what recovery requirement does the schedule serve?
• Where are backups and required redo retained, and how are credentials and recovery keys obtained securely?
• When is the next execution, in which time zone, and who investigates a missed or failed run?
• Which execution proves the configuration worked, and when was recovery last validated or rehearsed?

The next lesson is the module wrap-up. Carry forward the distinction between configuring a backup, scheduling its execution, and proving its usefulness for recovery.