Implement OCI Cyber Recovery for Oracle workloads from any source environment
This reference architecture provides a controlled environment for recovery validation, forensic analysis, and restoration of business services following a cyber incident.
The production workload can run on OCI, Oracle multicloud database services, another hyperscaler, or on-premises infrastructure. In all cases, the cyber recovery vault is deployed in a separate OCI tenancy and is operated as an independent recovery control plane.
The architecture is designed for Oracle application estates that rely on Oracle databases, including both Oracle AI Database and traditional Oracle database deployments. While the database is often the primary system of record, a usable recovery also requires the minimum set of application artifacts needed to reconstitute service. These artifacts can include application-tier backups, configuration files, shared file systems, deployment manifests, middleware configuration, container images, database wallets, encryption metadata, and recovery runbooks.
The cyber vault is a storage target and a controlled validation and recovery environment. Immutable backup copies are retained in Oracle Cloud Infrastructure Object Storage, but the key differentiator is that the vault contains the processes, automation, compute, database restore targets, scanning tools, and clean-room environment required to prove that selected recovery points are usable.
In this architecture, a separate cyber recovery tenancy stores immutable copies, remains air-gapped from production, and initiates copy operations from within the cyber recovery tenancy rather than extending broad production trust into the vault. It uses a separate cyber recovery tenancy, vault-side synchronization, immutable OCI Object Storage buckets, antivirus scanning, signature validation, and clean-room testing as core design principles.
The objective is not only to retain backups, but to ensure that they are:
- Recoverable
- Free from tampering
- Free from malware
What Makes This Architecture Different
Many cyber recovery offerings focus on storing backup copies in a managed service or managed provider tenancy and then scanning those backup objects for malware. That approach is useful, but it is incomplete for Oracle workloads.
This architecture goes further because the OCI vault includes validation processes inside the customer-controlled vault tenancy. The vault can restore databases temporarily, run Oracle-native validation, run customer-defined SQL validation scripts, validate application consistency, and produce evidence that a recovery point is usable.
This distinction is important because a backup can be:
- Present, but unable to be restored
- Immutable, but already corrupted before it was stored
- Malware-scanned, but logically tampered with at the application data layer
- Technically restorable, but missing wallets, configuration, file systems, or middleware artifacts
- Database-consistent, but not application-consistent
A storage-only or scan-only service typically can't validate business data inside a temporarily restored Oracle Database. This OCI-based vault can.
For Oracle workloads, the architecture validates at multiple layers:
- Backup file integrity: The vault verifies object presence, object size, checksum, metadata, and retention status.
- Oracle database recoverability:
RMAN validation checks that backup pieces are complete and restorable. Oracle RMAN
validate,restore... validate, andvalidate backupsetcan check for missing or damaged files, physical corruption, logical corruption where configured, and backup-set restorability. - Temporarily restored database validation: The clean room restores selected databases and runs workload-specific validation. Validation can include custom SQL scripts that check control totals, reconciliation balances, row-count baselines, high-value transaction samples, schema drift, invalid objects, application configuration tables, period status, user and role baselines, or other business invariants. These checks don't mathematically prove that no tampering ever occurred, but they can detect important classes of production-data tampering that backup object scanning can't detect.
- Application-level validation: The vault validates that the recovered database works with the minimum application stack required to resume business service
- Operational recovery evidence: The vault stores validation reports, restore logs, SQL validation results, scan results, and clean-room test outcomes as retained evidence.
cyber-recovery-pipeline-oracle.zip#GUID-17034D86-DC64-4F72-B26C-E42B9A34C3BC
- Backup generation: Databases, applications, and infrastructure backups are created in the production tenancy.
- Secure ingress and validation: Backups are securely transferred to the vault. Manifests and checksums are validated.
- Immutable storage: Backups are stored in OCI Object Storage buckets with retention rules, locked where required.
- RMAN validation: RMAN VALIDATE and crosscheck operations verify backup integrity and recoverability.
- Temporary restore clean room: Backups are restored in an isolated clean room environment within the vault tenancy.
- Custom SQL validation: Workload-specific SQL scripts validate data correctness, reconciliation, and business rules.
- Application validation: Application services are started, and smoke tests verify functionality and integrations.
- Scanning: AV and vulnerability: Malware scanning, such as ClamAV, and vulnerability scanning, such as OCI Vulnerability Scanning Service, are performed.
- Recovery evidence and approval: Results are collected, evidence is stored, and the recovery point is approved for use.
Key Outcomes:
- Backups are present and unaltered
- Backups are restorable with RMAN
- Data is validated with business rules
- Applications are verified for functionality
- Risks are scanned and reported
- Recovery point is proven and approved
Objectives
The architecture must ensure that recovery artifacts are:
- Recoverable: Database backups and application artifacts can be restored into a clean room under customer control.
- Tamper-resistant: Backup objects are protected by Oracle Cloud Infrastructure Object Storage retention rules. Time-bound retention rules prevent modification and deletion for the configured duration, and locked retention rules become irreversible after the mandatory lock delay. A locked retention rule can't be deleted, even by a tenancy administrator or Oracle Support.
- Independently controlled: The vault tenancy owns the retained backup artifacts. Production administrators and production automation don't have broad or permanent control over the vault copy of record.
- Validated: The vault performs deterministic integrity, restore, database, SQL, and application-level checks.
- Portable across source platforms: The same vault pattern applies whether the Oracle workload originates from OCI, another hyperscaler, Oracle multicloud database services, or on-premises infrastructure, if the source can produce a customer-controlled backup artifact that can be copied to Oracle Cloud Infrastructure Object Storage.
The objective is to help recover a minimum viable company after a destructive or ransomware event. The architecture preserves and validates the smallest set of Oracle-backed systems required to resume critical business operations.
Minimum Viable Company (MVC)
A minimum viable company is the smallest set of business services, applications, databases, users, integrations, and operational processes required for an organization to continue critical operations after a cyberattack. In a cyber recovery architecture, the MVC concept helps to prioritize which workloads must be restored first in the clean room and validated for business functionality before full enterprise recovery begins. Instead of attempting to recover the entire IT estate immediately, the solution focuses on rapidly restoring the core systems needed to sustain essential business operations, maintain financial and regulatory obligations, and support controlled business continuity. The concept of an MVC aligns closely with the UK National Cyber Security Centre (NCSC) Cyber Assessment Framework (CAF), which emphasizes identifying and recovering essential business functions and services after a cyber incident. The MVC represents the smallest set of business capabilities, applications, data, users, and operational processes required to sustain critical operations while broader enterprise recovery continues.
The following lists the phases of a minimum viable company (MVC) recovery model:
-
Phase 1: Establish Access & Core Platform
- Restore foundational services to enable secure access and basic operations
- Identity & Access Management (IAM)
- Networking & Connectivity (DNS, VPN, Bastion)
- Security & Monitoring (Logging, Cloud Guard)
- Object Storage Access (Service Gateway/PE)
Outcome: Secure access established to recover critical workloads.
-
Phase 2: Restore Core Data & Databases
- Restore core databases and data services required for business-critical functions
- Critical Oracle Databases (ERP, Finance, HR, and so on)
- Database Infrastructure (ASM, Listener, TDE Wallets)
- Key Data Stores (Identity, Reference Data)
- Backup Validation (RMAN validate)
Outcome: Core data and databases are available and validated.
-
Phase 3: Restore Critical Applications
- Restore the minimum set of applications and supporting services required to operate
- Application Servers (ERP, Middleware, Portal)
- Integration Services (Interfaces, APIs, Queues)
- Shared File Systems (Configurations, Uploads)
- Dependencies (Redis, MQ, Cache, and so on)
Outcome: Critical applications are running and integrated.
-
Phase 4: Validate Business & Operations
- Validate business processes and confirm the ability to operate the MVC
- Custom SQL Validation (Business Rules, Reconciliations)
- Application Smoke Tests (Key Functions & Transactions)
- User Access Validation (Roles, Permissions)
- Operational Readiness (Monitoring, Alerts, Jobs)
Outcome: Business processes are validated and operational within the MVC.
-
Phase 5: Extend & Full Recovery
- Extend recovery to additional systems and restore full enterprise capabilities
- Reporting & Analytics
- Non-Critical Applications & Workloads
- DR to Production (If required)
- Optimize & Scale (Performance, Capacity)
Outcome: Full enterprise capabilities are restored.
Key principles:
- Prioritize Business Outcomes: Focus on what is essential for the business to operate.
- Recover in Phases: Start small, validate, then expand.
- Validate Continuously: Prove each phase works before moving forward.
- Operate Securely: Maintain isolation, access control, and monitoring.
- Evidence Everything: Record results and retain audit evidence.
MVC delivers:
- Faster Recovery: Focus on the minimum needed to operate.
- Reduced Risk: Limit exposure and complexity during recovery.
- Lower Cost: Recover only what is needed when it is needed.
- Business Continuity: Maintain critical operations and regulatory obligations.
- Path to Full Recovery: Extend in a controlled and validated manner.
Architecture
Description of the illustration oci-cyber-recovery-workloads-arch.png
oci-cyber-recovery-workloads-arch-oracle.zip#GUID-562C8D8A-0AE0-4FB5-B26F-8C63CB5533A2
The diagram shows an Oracle workload running in OCI as the production source. The same architecture applies when the Oracle workload runs in Another hyperscaler, on Oracle multicloud database services, or on-premises. Only the source-side backup and transfer mechanism changes. The cyber vault, immutable storage, validation pipeline, scanning pipeline, and clean room remain on OCI.
The production environment creates database, application, file system, image, and configuration artifacts. Vault automation copies these artifacts into a separate OCI cyber recovery tenancy. Immutable OCI Object Storage buckets protect retained artifacts with retention rules. A deterministic validation pipeline checks object integrity, backup completeness, RMAN recoverability, and restored database consistency. The clean room temporarily restores selected databases and application components, runs custom SQL validation and application smoke tests, and stores recovery evidence. Optional scanning tools such as ClamAV and OCI Vulnerability Scanning inspect file-based artifacts, hosts, and container images. Optional analytics can analyze vault telemetry for anomalies, but the baseline architecture relies on deterministic validation and controlled restore testing.
The architecture includes the following environments:
- Production environment
- Vault ingress environment
- Immutable vault storage
- Deterministic validation environment
- Clean room validation and recovery environment
- Optional enhanced analytics and AI anomaly detection environment
Production Environment
The production Oracle workload can run in one of several locations:
- OCI
- Oracle AI Database@Azure
- Oracle AI Database@Google Cloud
- Oracle AI Database@AWS
- Another hyperscaler
- On-premises infrastructure
The architecture uses the same principle in every case: production must generate or expose a customer-controlled backup artifact that can be copied into the OCI cyber recovery tenancy.
For Oracle databases, the preferred artifact is an RMAN-compatible backup that the customer can restore under their own control. For Oracle applications, additional artifacts must be preserved, such as application binaries, middleware configuration, shared file systems, deployment manifests, certificates, wallets, keys, and operational runbooks.
This architecture does not position Oracle Database Zero Data Loss Autonomous Recovery Service as the cyber vault copy of record. The recovery service can be valuable for operational database protection, near-zero RPO objectives, and service-managed restore workflows, but the main requirement here is a customer-controlled backup artifact stored in a separate OCI cyber recovery tenancy. The cyber recovery tenancy must be able to independently own, retain, validate, and restore backup artifacts under customer control. The recovery service does not provide direct customer access to underlying backup files, and recovery service-protected backups are designed to be restored within the same production tenancy rather than exported and restored into an independent cyber recovery tenancy. Because this architecture depends on vault-owned immutable backup copies that can be restored and validated in an isolated clean room, don't use the recovery service as the backup source or vault copy of record for this design.
Vault Ingress Environment
The vault ingress layer runs in the cyber recovery tenancy. It performs controlled ingestion of backup artifacts from production or from an intermediate source location.
The preferred pattern is vault-initiated copy. Production grants narrowly scoped read access to specific backup locations, and automation running in the vault tenancy pulls new artifacts into the vault. This pattern avoids a permanent broad trust relationship from production into the vault.
For OCI source tenancies, the vault can use cross-tenancy IAM policy and OCI Object Storage copy operations and a synchronization script initiated from within the cyber recovery tenancy to copy new backup objects into the cyber recovery tenancy.
For non-OCI sources, the pattern can use one of the following methods:
- RMAN writes directly to a restricted Oracle Cloud Infrastructure Object Storage ingress bucket.
- Source-side automation writes backup artifacts to a restricted OCI ingress bucket.
- A temporary landing bucket is used, and vault-owned automation copies artifacts into retained immutable storage.
- Dedicated private connectivity, VPN, Oracle Cloud Infrastructure FastConnect, or customer-approved transfer tooling is used where required.
In most designs, don't treat the ingress bucket as the final vault copy of record. A safer model is to treat ingress as a landing or quarantine area, then perform a vault-owned copy into immutable vault storage after initial completeness and metadata checks.
Immutable Vault Storage
The vault stores recovery artifacts in private Oracle Cloud Infrastructure Object Storage buckets. Retention rules are used to prevent modification and deletion for the required retention period. Locked retention rules are used where the customer requires administrator-resistant immutability.
Use the following typical bucket layout:
- Ingress bucket. Receives newly copied artifacts. Access is tightly restricted. Retention may be short or absent depending on the design.
- Immutable database backup bucket. Stores RMAN backup pieces, archive logs, control file backups, SPFILE backups, and database backup manifests.
- Immutable application artifact bucket. Stores application-tier backups, configuration bundles, deployment manifests, middleware configuration, file system exports, container manifests, and recovery scripts.
- Manifest and evidence bucket. Stores backup manifests, hash reports, validation logs, RMAN validation output, SQL validation results, malware scan results, vulnerability scan reports, clean-room restore reports, and operator approvals.
- Restore staging bucket. Used by clean-room jobs when artifacts must be staged, unpacked, scanned, or transformed before restore.
- Optional second-region copy bucket. Used for regional survivability. Distinguish this copy from independent immutability. If a customer requires a second independently retained immutable copy, use a separate controlled copy process into a second retained bucket rather than relying only on replication semantics.
Deterministic Validation Environment
Deterministic validation is the baseline feature of the architecture. Include deterministic validation in every deployment.
The baseline validation pipeline includes the following checks:
- Object and manifest validation
Each backup cycle must produce a manifest that records:
- Source system
- Database name
- DBID
- Incarnation
- Backup tag
- Backup start and end time
- Object names
- Object sizes
- Checksums or hashes
- Encryption dependencies
- Wallet or key dependencies
- Retention period
- Application artifact dependencies
- Clean-room validation status
Vault automation compares the manifest with the objects copied into the vault. Missing objects, unexpected object counts, size mismatches, checksum mismatches, and unexpected timestamp changes must raise an alert.
- Retention and storage-policy validation
The vault verifies the following requirements:
- Buckets are private
- Retention rules are present
- Retention rules are locked where policy requires
- Encryption meets customer policy
- Only approved vault automation can write to immutable buckets
- Only approved validation and recovery roles can read retained objects
- Oracle Cloud Guard findings are reviewed
- Oracle database backup validation
The vault uses RMAN-native validation for database backups.
RMAN can validate backup sets, check for missing or damaged backup pieces, validate that backups can be restored, and check physical and logical corruption depending on the command and options used.
The exact command set depends on database version, backup method, restore target, recovery catalog design, and customer policy.
- Temporarily restored database validation
Temporary database restore validation differentiates this architecture from cyber solutions that only store and scan backup objects.
At defined intervals, the clean room restores selected databases from retained vault backups. After restore, the validation pipeline runs customer-defined SQL checks against the temporary database.
For application-specific workloads, the customer can add SQL validation scripts that check known-good business invariants. Examples include reconciliation totals, ledger balances, transaction counts, period status, reference-data checks, application profile options, interface queue status, and other workload-specific controls.
The purpose is not only to prove that the backup can be restored. The purpose is to detect signs that production data may have been manipulated before the backup was taken. This capability is important for Oracle ERP, EPM, financial services, and other database-centric application estates.
- Periodic application testing
Periodically, the clean room starts or simulates the minimum application services required to prove business recovery.
Application validation can include the following checks:
- Application service startup
- Middleware startup
- Listener and connection checks
- Application login checks
- Batch scheduler checks
- Integration endpoint checks
- Critical report execution
- Critical transaction read-only validation
- Comparison with recovery acceptance criteria
The goal is to prove that the selected recovery point can support the complete workload recovery.
- Scanning in the vault
Include scanning, but distinguish between malware scanning, vulnerability scanning, and database validation.
- Malware scanning with ClamAV
A baseline malware scanning option can use ClamAV deployed on OCI Compute, OCI Oracle Cloud Infrastructure Container Instances, or Kubernetes Engine inside the vault tenancy. ClamAV is an open source antivirus engine for detecting trojans, viruses, malware, and other malicious threats, and it includes command-line utilities, an on-demand scanner, a scanner daemon, and signature updates.
In this architecture, ClamAV is not an OCI managed service. ClamAV is a customer-managed open source scanner that runs on OCI infrastructure inside the vault. It can be used as a free or low-cost baseline scanner for application archives, scripts, exported file systems, container layers, and other file-based artifacts.
ClamAV or any other malware scanning solution should not be positioned as sufficient validation for Oracle Database backups. Database backup validation uses RMAN and clean-room restore testing.
- OCI Vulnerability Scanning
Use OCI Vulnerability Scanning Service for OCI-native vulnerability checks on hosts and container images. Oracle documentation states that OCI Vulnerability Scanning routinely checks hosts and container images for vulnerabilities and provides reports with metrics, details, and remediation information.
For Kubernetes Engine and containerized Oracle application stacks, store required images in Oracle Cloud Infrastructure Registry and enable image scanning. Oracle Cloud Infrastructure Registry image scanning uses OCI Vulnerability Scanning; images pushed to enabled repositories are scanned for vulnerabilities, and repositories are rescanned when new vulnerabilities are added to the CVE database.
- Optional third-party scanners
Customers can implement other malware, vulnerability, or container security scanners in the vault. Run those scanners on OCI services such as OCI Compute, Kubernetes Engine, Oracle Cloud Infrastructure Container Instances, Oracle Cloud Infrastructure Functions, or Marketplace-provided appliances, and follow the same vault isolation model.
Treat the scanning pipeline as additive. Scanning can identify malware and known vulnerabilities, but it does not replace RMAN validation, SQL data validation, clean-room restore, or application smoke testing.
Clean Room Validation and Recovery Environment
The clean room is an isolated OCI VCN in the cyber recovery tenancy. The clean room is used for controlled restore, database validation, malware scanning, vulnerability scanning, SQL validation, application smoke testing, and emergency recovery.
The architecture doesn't extend a production trust boundary into the clean room. Access must be time-bound, audited, and restricted to approved recovery operators. The clean room must use private subnets, restricted egress, private access to OCI Object Storage, and tightly controlled administrative access.
The clean room supports two operating modes:
- Validation mode
Validation mode is used during scheduled recovery exercises. It restores selected databases and application components, runs deterministic checks, stores evidence, and then tears down or resets temporary resources.
Validation mode tests the following items:
- RMAN restore
- Database open
- SQL validation scripts
- Application connectivity
- Middleware startup
- Selected business processes
- Availability of required wallets, certificates, and keys
- Recovery-time measurements
- Operator runbook accuracy
- Recovery mode
Recovery mode is used during an actual cyber event. The clean room becomes the staging environment for restoring and validating the minimum viable company before workloads are promoted, rebuilt, or connected to users.
Recovery mode supports the following operations:
- Recovery-point selection
- Restore of database and application artifacts
- Forensic inspection where required
- Malware and vulnerability scanning
- SQL tamper-detection checks
- Business-owner validation
- Controlled network opening
- Staged recovery of critical services
AI Anomaly Detection Environment
AI-based anomaly detection is an optional enhancement, not a baseline requirement for the recovery architecture.
The baseline recovery process should rely on deterministic validation controls, such as manifest checks, checksum verification, RMAN validation, SQL validation, clean-room restore, and application smoke testing. These controls are easier to audit, produce repeatable results, and provide direct evidence that the environment can be recovered.
An optional analytics or anomaly detection enclave can be added where operational maturity, telemetry quality, and governance processes support it. This enclave can analyze vault-local telemetry and backup metadata, including:
- Backup size changes o Backup frequency changes
- Missed backup cycles o Copy-job failures
- Validation failures
- Checksum mismatches
- RMAN errors
- SQL validation failures
- Retention-rule changes
- Unusual object reads
- Failed administrative actions
- Oracle Cloud Guard findings
- Clean-room restore duration changes
- Unexpected changes in container image versions
This enhanced layer analyzes telemetry and metadata retained within the recovery environment. It does not inspect live production traffic. Its purpose is to highlight anomalies and prioritize investigation, while recovery approval remains based on deterministic validation results and acceptance by the appropriate application or business owner.
Recommendations
- OCI source workload considerations
When production runs on OCI, the source estate can include databases, compute instances, block volumes, boot volumes, file systems, Kubernetes Engine persistent volumes, and container images.
- Database backups
Use customer-controlled RMAN or service tooling that produces customer-operable backup artifacts in Oracle Cloud Infrastructure Object Storage. The artifacts are then copied into the cyber recovery tenancy and protected by retention rules.
- Block volume backups
For non-boot block volumes, Oracle Cloud Infrastructure Block Volumes backups can protect application data volumes, middleware volumes, or custom software volumes. The vault design must preserve the ability to restore those volumes into the clean room.
-
Boot volume backups and custom images
For OCI boot volumes, the documented export path outside the production tenancy for a bootable image is to create a custom image from the instance that uses the boot volume, then export that custom image to OCI Object Storage.
Therefore, for bootable application servers in OCI production, the vault pattern is:
- Create a custom image from the instance.
- Export the custom image to OCI Object Storage.
- Copy the exported image object into the cyber recovery tenancy.
- Protect the exported image object with OCI Object Storage retention rules.
- Import or use the image during clean-room validation or recovery.
Oracle’s custom image export documentation states that exported images are copies of the VM or bare metal instance boot volume and metadata at the time the image is created, and that export copies the data to the specified OCI Object Storage location. The export formats include VMDK, VHD, VDI, QCOW2, and OCI image format.
The application-tier boot volumes often contain important binaries, operating-system configuration, agents, scripts, and middleware installation details.
-
Oracle Cloud Infrastructure File Storage
For shared application file systems, use Oracle Cloud Infrastructure File Storage snapshots or file-level backup exports into OCI Object Storage. The selected pattern must preserve application consistency and support clean-room restore.
-
Kubernetes Engine and containerized application stacks
For Kubernetes Engine-based Oracle application stacks, preserve the following items:
- Kubernetes manifests
- Helm charts or deployment templates
- Container images
- Persistent volume backups or snapshots
- Application secrets recovery process
- Ingress and service definitions
- Database connectivity configuration
- Image scan reports
Use OCI Vulnerability Scanning Service for container images in Oracle Cloud Infrastructure Registry and optionally add ClamAV or third-party scanners for file-level artifacts where appropriate.
Considerations
-
For Oracle workloads that run outside OCI, the vault principle remains unchanged: the production environment must produce a customer-controlled artifact that the OCI cyber recovery tenancy can own, retain, validate, and restore.
For Oracle databases, that typically means RMAN-compatible backup pieces written to Oracle Cloud Infrastructure Object Storage or copied into Oracle Cloud Infrastructure Object Storage through a controlled transfer process.
-
For application tiers that run outside OCI, the customer must export or package the following artifacts:
- Virtual machine images where required
- Application binaries
- Middleware configuration
- File system backups
- Kubernetes manifests
- Container images
- Secrets recovery procedure
- Certificates and wallets
- Runbooks
Choose the target format based on clean-room restore requirements. The vault must not retain only opaque provider-managed backups if those backups cannot be restored under customer control in the OCI clean room.
-
Validated Recovery as a Cyber Recovery Control Plane: The OCI Cyber Recovery Solution differs from backup-only or scan-only cyber recovery offerings because it provides a customer-controlled validation and recovery platform inside a separate OCI tenancy.
The vault not only retains backups, the vault restores them, validates them, scans applicable artifacts, runs Oracle-native RMAN checks, executes customer-defined SQL validation against temporarily restored databases, verifies application readiness, and produces auditable evidence of recoverability.