Backing up your Oracle 12c database is not just a best practice—it’s essential for business continuity. A reliable backup strategy protects your data from hardware failures, user mistakes, or disasters like ransomware attacks. In this article, you’ll learn how to create and schedule an RMAN full backup script for Oracle 12c step by step. Whether you’re new to RMAN or want to automate your backup process, you’ll find clear guidance here.
What is RMAN Full Backup?
A full backup in RMAN (Recovery Manager) creates a complete copy of your database’s data files while skipping unused space for efficiency. This type of backup can also include archived redo logs and control files if specified—ensuring you can restore your database to a consistent state after any failure.
RMAN full backups are essential because they capture all active blocks in the database at the time of execution. By including archived redo logs and control files in your routine, you ensure point-in-time recovery options remain available.
Why Use RMAN for Oracle 12c?
RMAN is Oracle’s built-in tool designed specifically for efficient backup and recovery tasks. It integrates tightly with Oracle 12c databases—including both traditional single-instance setups and multitenant environments (CDB/PDB). With RMAN, you get automated block-level corruption checks, easy management of retention policies, cataloging features for tracking backups over time—and most importantly—the ability to perform online (hot) backups without shutting down production systems.
You can run RMAN interactively or automate it through scripts and schedulers—making it suitable whether you manage one database or hundreds across different servers.
Method 1: Basic RMAN Full Backup Script
Starting with the basics helps build confidence before moving to advanced automation or optimization techniques.
Before running any full backup using RMAN in Oracle 12c:
Make sure your database is in ARCHIVELOG mode so that online (hot) backups are possible.
Check that archive log destinations (LOG_ARCHIVE_DEST_1) are configured properly; otherwise enabling ARCHIVELOG mode may fail.
Plan maintenance windows if switching modes during production hours since some downtime is required.
To check current log mode:
SQL> archive log list;
If ARCHIVELOG mode isn’t enabled yet:
1. Ensure no critical users are connected
2. Schedule downtime if needed
3. Run these commands:
SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database archivelog;
SQL> alter database open;
Now let’s create a simple script that backs up everything—including archived logs and control file—for maximum recoverability:
Example: Basic Full Backup Script
BACKUP DATABASE PLUS ARCHIVELOG;
This command does several things:
Forces an ALTER SYSTEM ARCHIVE LOG CURRENT
Backs up all archived redo logs generated so far
Backs up all data files
Archives remaining redo logs again after datafile copy completes
If you want to specify where the backup files go:
BACKUP DATABASE FORMAT '/u01/app/oracle/backup/%U' PLUS ARCHIVELOG FORMAT '/u01/app/oracle/backup/%U';
To run this interactively:
1. Log in as the Oracle user on your server
2. Start RMAN:
$ rman target /
3. At the RMAN prompt enter your command directly—or use a command file by saving commands into backup_script.rman then running:
RMAN> @/path/to/your/backup_script.rman
For multitenant setups:
BACKUP DATABASE;
Note: Only PDBs currently open will be included; unplugged or mounted-only PDBs won’t be backed up unless opened first.
BACKUP PLUGGABLE DATABASE pdb1;
You can tag each backup job for easier identification later:
BACKUP DATABASE TAG 'FULL_BACKUP';
After completing any backup job always check status using:
LIST BACKUP;
And keep things tidy by removing obsolete copies with:
DELETE NOPROMPT OBSOLETE;
This prevents disk space issues over time.
For extra safety after listing backups run these maintenance commands regularly:
CROSSCHECK BACKUP;
DELETE EXPIRED;
These steps help avoid confusion between missing files on disk versus what’s recorded in metadata.
Method 2: Scheduling RMAN Backups in Oracle 12c Using DBMS_SCHEDULER or Cron Jobs
Manual runs work fine—but automation ensures consistency even when staff changes occur or holidays come around! There are two main ways to schedule regular jobs: inside Oracle itself (DBMS_SCHEDULER) or outside via operating system tools like cron (Linux/Unix).
Using DBMS_SCHEDULER
Oracle's built-in scheduler lets you define jobs entirely within the database environment—no need for external tools unless desired.
First create a shell script containing your optimized commands—for example /u01/app/oracle/scripts/rman_full_backup.sh—
Be sure it starts with #!/bin/bash at top,
and sets environment variables correctly (ORACLE_SID, ORACLE_HOME, PATH) since scheduled jobs often lack normal login context.
Make it executable too!
Example content:
#!/bin/bash
export ORACLE_SID=yourdb
export ORACLE_HOME=/u01/app/oracle/product/12.2.0/dbhome_1
export PATH=$ORACLE_HOME/bin:$PATH
rman target / LOG /u01/app/oracle/scripts/log/rman_backup_$(date +%Y%m%d).log <<EOF
BACKUP AS COMPRESSED BACKUPSET DATABASE PLUS ARCHIVELOG;
DELETE NOPROMPT OBSOLETE;
EOF
chmod +x /u01/app/oracle/scripts/rman_full_backup.sh
Now register this script as a scheduled job inside Oracle using SQL*Plus—
BEGIN
DBMS_SCHEDULER.create_job (
job_name => 'RMAN_FULL_BACKUP_JOB',
job_type => 'EXECUTABLE',
job_action => '/u01/app/oracle/scripts/rman_full_backup.sh',
start_date => SYSTIMESTAMP,
repeat_interval => 'FREQ=DAILY;BYHOUR=2;BYMINUTE=0;BYSECOND=0',
enabled => TRUE);
END;
/
This schedules nightly runs at exactly 2 AM server time.
Remember never hardcode passwords into scripts—instead use OS authentication (target /) wherever possible.
Using Cron Jobs (Linux/Unix)
Cron remains popular because it's simple and reliable—even outside of Oracle environments.
Edit crontab as the oracle user (crontab -e) then add this line near bottom—
0 2 * * * /u01/app/oracle/scripts/rman_full_backup.sh
Cron will now launch your shell script automatically each day at precisely 2 AM.
Again double-check that all environment variables (ORACLE_SID, ORACLE_HOME, PATH) appear explicitly within any called shell scripts since cron provides only minimal defaults.
How to Protect Oracle Database with Vinchin Backup & Recovery?
While manual scripting offers flexibility, enterprise environments often require streamlined solutions with robust feature sets for comprehensive protection. Vinchin Backup & Recovery stands out as a professional enterprise-level solution supporting today’s mainstream databases—including Oracle, MySQL, SQL Server, MariaDB, PostgreSQL, PostgresPro, and TiDB—with special emphasis on seamless integration for Oracle environments like yours.
Key features such as advanced source-side compression, incremental backup capabilities, batch database operations, multi-level data compression strategies, and flexible retention policies deliver significant benefits: reducing storage costs, accelerating backup cycles, simplifying management across multiple instances, ensuring compliance requirements are met efficiently—all while maintaining high performance standards demanded by mission-critical workloads.
The intuitive web console makes safeguarding your Oracle databases straightforward:
Step 1. Select the Oracle database to back up
Step 2. Choose the backup storage
Step 3. Define the backup strategy
Step 4. Submit the job—no steep learning curve required.
Vinchin Backup & Recovery enjoys global recognition among enterprises seeking reliable data protection software—join thousands of satisfied customers worldwide by starting your free 60-day full-featured trial today via our download link below!
RMAN Full Backup Script Oracle 12c FAQs
Q1: How do I set automatic deletion of old backups?
A1: Configure retention policy using CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF n DAYS then include DELETE NOPROMPT OBSOLETE in every scheduled script run.
Q2: Is there a way to test my restore process without affecting production?
A2: Yes—use RESTORE DATABASE VALIDATE which checks integrity without changing live data or requiring downtime.
Q3: What should I do if my scheduled cron job fails silently?
A3: Check permissions on both script/log directories > Confirm environment variables set inside script > Review generated log file > Test manual execution as same user.
Conclusion
A solid RMAN full backup script forms the backbone of any effective protection plan for Oracle 12c databases—from small businesses to global enterprises alike! Automate wisely—and remember Vinchin offers even greater simplicity plus peace-of-mind through its unified platform approach—all available now via free trial download!
