The Compute Challenge: Achieving Immutability Without Base DB Service
In the first and second Episode, we covered the gold standard for E-Business Suite on OCI: leveraging the powerful automation of the Base Database Service and Autonomous Recovery Service (ARS).
But what if your architecture mandates running the EBS database on a standard Compute instance (IaaS)? This scenario, common for highly customized environments or specific licensing models, strips away the native DR automation, forcing a more hands-on approach to achieving our goal of immutable, ransomware-proof backups.
At Broadpin, we tackle these bespoke architectures head-on. Here is how we extended our "Fortress Strategy" for an EBS database running on Compute.
The Architecture & Trade-Offs
When running the database on Compute, we lose two major features of ARS:
- Zero Data Loss: We must rely on standard RMAN archivelog backups, not continuous synchronization.
- Incremental Forever: Backup and restore operations will be more time-consuming due to the reliance on traditional incremental/full RMAN backups.
Database Backup Strategy: OCI Cloud Backup Module
Since ARS is unavailable, we use the Database Cloud Backup Module (libopc.so) to push RMAN backups directly to OCI Object Storage.
1. RMAN Configuration (Full Backup):
To establish the weekly immutable full backup, we configured RMAN to use the SBT (System Backup to Tape) library and specified the OCI configuration file (opcISDBackup.ora).
SET ENCRYPTION ON IDENTIFIED BY XXXXX ONLY;
CONFIGURE DEFAULT DEVICE TYPE TO 'SBT_TAPE';
CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 6 BACKUP TYPE TO COMPRESSED BACKUPSET;
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS='SBT_LIBRARY=/u01/install/APPS/19.0.0/lib/libopc.so, SBT_PARMS=(OPC_PFILE=/home/oracle/opcBackup.ora)';
run {
backup incremental level 0 cumulative database;
sql 'alter system switch logfile';
backup format '%d_%T_%U.bkp0Arch' archivelog all not backed up delete input;
}
2. Achieving Database Immutability:
To ensure these RMAN backups are undeletable, we must apply the same Retention Rule (e.g., a 35-day lock) to the target Object Storage bucket (PROD_APPS).
Important: RMAN's Cloud Backup Module requires a separate, temporary bucket for staging data during the backup process. This is a crucial detail for configuration, as outlined in Oracle's documentation.
Phase 1: Application Tier Backup
The App Tier strategy remains similar to Episode 1, but we must now also capture the Oracle Home for the Database, as it reside on standard filesystems.
We updated our weekly script to capture the DB Oracle Home (/u01/install/APPS/19.0.0) along with the application directories and OCI configuration files, piping the output directly to the locked Object Storage bucket.
#!/bin/bash
HOST=$(hostname -s)
SID="MAST"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
ARCHIVE_NAME="bkp_full${SID}_${HOST}_${TIMESTAMP}.tgz"
tar -cz /u01/install/APPS/19.0.0 /u01/install/APPS/scripts /home/oracle/opcISDBackup.ora | oci os object put --bucket-name PROD_APPS --auth instance_principal --file - --name ${ARCHIVE_NAME}
Phase 2: The Manual Restore Procedure
The biggest change is in the recovery workflow. Since we're not leveraging the OCI console's "Restore Database," the process relies on manually recovering the filesystems and then using RMAN.
1. Restore the Oracle Homes (The Filesystem)
The first step is identical to Episode 2's App Tier restore: spin up the new Compute instance and use the oci os object get command to restore the tgz file containing the EBS filesystems, including the DB Oracle Home.
2. RMAN Restore and Recovery
With the Oracle Home and executables back in place, we can start the database in NOMOUNT mode, connect RMAN, and utilize the Cloud Backup Module to retrieve the database files from the locked Object Storage bucket.
3. Final Configuration (Simplified)
A major benefit of including the Oracle Homes in our initial filesystem backup is that the DB's appsutil directory is already restored.
Once the database is recovered, the final step is to run AutoConfig on the DB Tier, which registers the instance's new location and allows connection from the restored Application Tier.
A modern EBS environment isn't just Forms and Reports. We also reconfigured:
- ORDS: Re-installed/configured to point to the new DB service for APEX support.
- Enterprise Command Center (ECC): Created a new DBC file and updated some IP Addresses in the config files.
Alternative Strategy: Boot Volume Backups
While this post focuses on achieving immutable backups for ultimate ransomware protection, for non-critical environments or simpler DR needs, a simpler (but non-immutable) strategy exists: Boot Volume Backups.
Standard boot volume backups of the DB and App compute instances are quick and easy to manage via OCI Policy-Based backup features. However, remember they lack the retention lock we sought for our immutable fortress.
For a look at a simpler, non-immutable backup strategy for Compute-based EBS, you can reference this previous post: Backing Up E-Business Suite Instances on OCI
Conclusion
Whether you choose the automated approach of Base Database Service or the manual control of a Compute instance, achieving a high level of ransomware protection in OCI is achievable through strategic use of Object Storage Retention Rules. While the Compute route involves more hands-on configuration and incurs longer recovery times, it provides the same immutable guarantee.
The Broadpin team specializes in navigating these architectural complexities to deliver robust, secure, and resilient EBS solutions in the cloud.