Backing up your Oracle Real Application Clusters (RAC) database is essential for business continuity. In clustered environments, data is stored on shared disks accessed by multiple nodes at once. This setup boosts availability but also adds complexity when it comes to backups—especially with archive logs generated by each node. Many administrators use Oracle Recovery Manager (RMAN) scripts to automate this process because they are reliable and cluster-aware. But how do you write a robust script for Oracle RAC? And how can you schedule it so that backups run automatically without manual intervention? In this guide, we’ll walk through the basics of scripting, show you working examples, explain automation using cron, discuss advanced considerations unique to RAC setups, and cover how Vinchin can simplify enterprise-grade Oracle RAC backups.
What is Oracle RAC?
Oracle Real Application Clusters (RAC) is a high-availability solution from Oracle that lets several servers—or nodes—access one database stored on shared storage such as ASM or a clustered file system. If one node fails, others keep serving users without interruption. Each node runs its own instance but shares access to all data files and redo logs on disk.
This architecture means that every instance generates its own thread of redo logs—so your backup strategy must account for all these threads across the cluster. That’s why understanding both the physical layout (shared disks) and logical structure (multiple redo log streams) is key before building any automated backup solution.
What is RMAN in Oracle?
Recovery Manager (RMAN) is Oracle’s built-in tool for backing up and restoring databases efficiently—even in clustered environments like RAC. RMAN supports full database backups, incremental backups at various levels, archived log management across all instances in a cluster, plus control file and SPFILE protection.
Because RMAN understands clusters natively, it coordinates tasks between nodes so you get consistent results even if some instances are offline during backup time. It also automates many complex steps: allocating channels for parallelism; optimizing which files need copying; deleting obsolete archive logs after successful backups; tracking retention policies; and more.
Why use RMAN for Oracle RAC backups?
RMAN was designed with clustering in mind—it recognizes multiple nodes writing different redo log threads yet sharing common datafiles on disk. When you back up with RMAN:
It collects archived logs from every active thread across all nodes
It uses parallel channels to speed up large-scale operations
It ensures consistency by coordinating checkpoints
It reduces manual errors compared to ad-hoc scripting
With these features combined, your chances of getting recoverable—and restorable—backups go way up even as your environment grows more complex.
Method 1: Basic oracle rac rman backup script
Let’s start simple: You can use a shell script that calls RMAN with command files tailored for either full or Incremental backups. This approach works well whether you have just one instance or several clustered together—as long as environment variables are set correctly so each session knows which SID it’s targeting.
First step: Create two separate command files—one for level 0 (full) backups (backup_level0.rman), another for level 1 (incremental) (backup_level1.rman). Here’s what they look like:
backup_level0.rman
RUN {
ALLOCATE CHANNEL CH1 DEVICE TYPE DISK;
ALLOCATE CHANNEL CH2 DEVICE TYPE DISK;
BACKUP tag 'INCR0_DB' AS COMPRESSED BACKUPSET INCREMENTAL LEVEL 0 DATABASE PLUS ARCHIVELOG DELETE INPUT;
BACKUP CURRENT CONTROLFILE TAG 'INCR0_CTL';
BACKUP SPFILE TAG 'INCR0_SPFILE';
RELEASE CHANNEL CH1;
RELEASE CHANNEL CH2;
}backup_level1.rman
RUN {
ALLOCATE CHANNEL CH1 DEVICE TYPE DISK;
ALLOCATE CHANNEL CH2 DEVICE TYPE DISK;
BACKUP tag 'INCR_L1_DB' AS COMPRESSED BACKUPSET INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG DELETE INPUT;
BACKUP CURRENT CONTROLFILE TAG 'INCR_L1_CTL';
BACKUP SPFILE TAG 'INCR_L1_SPFILE';
RELEASE CHANNEL CH1;
RELEASE CHANNEL CH2;
}Next: Build a shell script called backup_rman.sh. This script takes two arguments—the target SID (-d) or "A" for all SIDs found in /etc/oratab, plus the desired backup level (-l). The script sets environment variables based on SID selection so each invocation targets the right database instance.
backup_rman.sh
#!/bin/bash
# Usage: ./backup_rman.sh -d ORACLE_SID -l BACKUP_LEVEL
# ORACLE_SID: The Oracle System ID (SID) or A for all databases.
# BACKUP_LEVEL: The backup level, either 0 or 1.
SCRIPT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" &> /dev/null && pwd )"
ORATAB="/etc/oratab"
if [ $# -eq 0 ]; then
echo "Usage: $0 -d ORACLE_SID -l BACKUP_LEVEL"
exit 1
fi
DB_SID=""
LEVEL=""
while getopts ":d:l:" opt; do
case $opt in
d) DB_SID="$OPTARG" ;;
l) LEVEL="$OPTARG" ;;
\?) echo "Invalid option -$OPTARG" >&2; exit 1 ;;
esac
done
if [ -z "$LEVEL" ]; then
echo "Warning: Backup level not specified. Please provide a backup level (0 or 1)."
exit 1
fi
perform_backup() {
local sid=$1
local level=$2
local level_tag="L${level}"
LOG_FILE="${SCRIPT_DIR}/rman_backup_${sid}_${level_tag}_$(date '+%Y%m%d_%H%M%S').log"
ORACLE_HOME=$(grep ^$sid: $ORATAB | cut -d: -f2)
export ORACLE_HOME
export ORACLE_SID=$sid
export PATH=$PATH:$ORACLE_HOME/bin
# Pre-backup check – confirm DB state is OPEN or MOUNTED:
db_state=$(echo "SELECT open_mode FROM v\$database;" | sqlplus -s / as sysdba | grep -E "READ WRITE|MOUNTED")
if [ -z "$db_state" ]; then
echo "Database $sid not OPEN or MOUNTED – skipping." | tee -a $LOG_FILE
return
fi
echo "Backing up database ORACLE_SID=$sid at level $level"
local cmdfile="${SCRIPT_DIR}/backup_level${level}.rman"
rman target / log=$LOG_FILE cmdfile=$cmdfile
# Error handling:
if [ $? -eq 0 ]; then
echo "Backup succeeded for $sid" | tee -a $LOG_FILE
else
echo "BACKUP FAILED for $sid – Check $LOG_FILE" >&2 | tee -a $LOG_FILE
return
fi
}
if [ "$DB_SID" = "A" ]; then
grep -v '^#' $ORATAB | grep -v '^\*' | cut -d: -f1 | while read sid; do
if [ -n "$sid" ]; then perform_backup "$sid" "$LEVEL"; fi
done
else
if grep -q "^$DB_SID:" $ORATAB; then
perform_backup "$DB_SID" "$LEVEL"
else
echo "The Oracle SID provided does not exist in /etc/oratab."
exit 1
fi
fiTo run a full (level 0) backup of mydb1, enter:
./backup_rman.sh -d mydb1 -l 0
For an incremental (level 1):
./backup_rman.sh -d mydb1 -l 1
To back up every database listed in /etc/oratab:
./backup_rman.sh -d A -l 0
This script sets required environment variables per SID found in /etc/oratab, checks that each target database is open/mounted before running RMAN commands from the correct directory, chooses the right command file based on requested backup type—and writes detailed logs per operation so you always know what happened where.
Method 2: Automating oracle rac rman backup script with cron
Manual execution leaves room for human error—or simply forgetting altogether! Automation guarantees regularity regardless of staff schedules or holidays.
On Linux/UNIX platforms most admins rely on cron jobs managed under their dedicated “oracle” user account:
First make sure your shell script has execute permissions:
chmod +x backup_rman.sh
Then edit crontab entries using:
crontab -e
Add lines like these depending on frequency needed—for example,
to run a full weekly Level 0 every Sunday at 02:00 AM:
0 2 * * 0 /path/to/backup_rman.sh -d mydb1 -l 0 >> /var/log/oracle_backup_cron.log 2>&1
And daily Level 1 incrementals Monday–Saturday at same hour:
0 2 * * 1-6 /path/to/backup_rman.sh -d mydb1 -l 1 >> /var/log/oracle_backup_cron.log 2>&1
Redirecting output into /var/log/oracle_backup_cron.log helps centralize monitoring—a crucial step when managing production workloads spread over several machines! Integrate this logfile into broader IT monitoring tools if possible so alerts trigger quickly upon failures rather than waiting until next business day review.
Always check both logfiles created by your scripts and overall cron job outputs regularly—you want confirmation messages (“Backup succeeded”) rather than silent failures lurking unnoticed!
If you’re scheduling jobs within a cluster context always ensure only one designated node runs them unless explicitly coordinating distributed tasks among several hosts using lockfiles or similar mechanisms.
How to back up Oracle RAC databases with Vinchin?
For organizations seeking streamlined protection beyond manual scripting, Vinchin Backup & Recovery delivers professional enterprise-level database backup tailored specifically for complex environments like Oracle—including comprehensive support for Oracle RAC deployments—as well as MySQL, SQL Server, MariaDB, PostgreSQL, PostgresPro, and TiDB.
Vinchin Backup & Recovery offers powerful features such as batch database backup management across clusters, granular data retention policies including GFS options, cloud/tape archiving integration, restore-to-new-server workflows ideal for disaster recovery scenarios, and built-in integrity checking routines—all designed to simplify administration while ensuring compliance and recoverability at scale.
The intuitive web console makes safeguarding an entire Oracle deployment remarkably easy through four guided steps:
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
Vinchin Backup & Recovery enjoys global recognition among enterprises seeking robust data protection solutions—with top ratings from customers worldwide. Experience every feature free with a no-obligation sixty-day trial by clicking download below.
oracle rac rman backup script FAQs
Q1: Can I validate an existing RMAN backup without restoring data?
A1: Yes—use VALIDATE BACKUPSET within RMAN to check integrity without affecting live data.
Q2: How often should I test restore procedures from my oracle rac rman backups?
A2: Schedule periodic recovery drills using recent backups onto non-production systems at least quarterly—or after major changes/upgrades—to verify end-to-end reliability.
Q3: What happens if archive logs aren’t deleted after successful RMAN runs?
A3: They accumulate until manually removed—which may fill storage volumes over time; always monitor space usage closely.
Conclusion
Automating oracle rac rman backup scripts delivers reliable protection—even as clusters scale out—but requires careful planning around scheduling, validation, and monitoring. For maximum simplicity plus advanced features consider trying Vinchin’s powerful solution today—with no risk thanks to their free trial offer!
