Get Started With Full Stack Disaster Recovery

Learn about accessing Full Stack DR, prerequisites, and understand the workflow for using the service.

How Full Stack Disaster Recovery Works

Full Stack Disaster Recovery protects application stacks by grouping their components and dependencies into dedicated DR configurations, creating and customizing automated migration workflows, testing them, and executing validated plans for planned or unplanned operations. Supported resources include compute, storage, file systems, databases, Object Storage, OKE, Integration, load balancers, and network load balancers. Configurations can be intra-region or cross-region, with cross-region deployment recommended for region-wide outage protection.

How To Access Full Stack Disaster Recovery

Full Stack Disaster Recovery is accessible through the OCI Console, CLI, REST APIs, language-specific SDKs, Terraform Provider, and Windows PowerShell. Console users select a region, open Migration & Disaster Recovery, and access Disaster Recovery or DR Protection Groups. CLI users use the OCI disaster-recovery command set, while API and SDK users connect through regional endpoints or supported programming languages.

Prerequisites For Full Stack Disaster Recovery

Using Full Stack DR requires preparation of the protected resources, including compute instances, Object Storage, block storage, supported databases, OKE, Integration instances, applications, file systems, and custom workflow actions. Prerequisites include creating log locations, configuring replication or standby resources, preparing scripts and mounts, and establishing IAM policies that permit Full Stack DR to manage the environment.

Who Can Use Full Stack Disaster Recovery

Full Stack DR is available to Oracle Cloud customers with Universal Credits or Pay As You Go in supported commercial, government, sovereign, Alloy, and Dedicated Regions, but it is unavailable in the Free Tier. Supported commercial locations span regions across Australia, the Americas, Europe, Asia-Pacific, the Middle East, and Africa, with availability domains varying by region; Alloy and Dedicated Region use requires ownership of two such regions.

Preparing Log Location For Operation Logs

Full Stack DR stores operation logs in OCI Object Storage, requiring a bucket before DR configurations are created. Oracle recommends one dedicated Standard-tier bucket per DR protection group, without replication, retention policies, or unrelated data, and with write access for the identity executing DR plans.

Preparing Compute Instances For Full Stack Disaster Recovery

Each protected compute instance should have a block volume group in the same availability domain containing its boot volume and all attached block volumes. If DR workflows run custom commands, configure IAM permissions for the Oracle Cloud Agent and provide appropriate sudo or administrator access, including Run Command permissions for operations requiring elevated privileges.

Preparing Object Storage For Full Stack Disaster Recovery

Prepare Object Storage replication by creating the destination bucket first, then configuring a replication policy on the source bucket with a name, destination region, and destination bucket. Replication supports one policy per source, one source per destination, and one destination per source; the destination becomes read-only, receives automatic object updates and deletions, and cannot be reused or deleted until replication is stopped.

Preparing Block Storage For Full Stack Disaster Recovery

Prepare block storage by grouping the relevant boot and block volumes, selecting a recovery region, and configuring volume-group replication or backups to that region. Moving-instance topologies generally replicate boot and attached data volumes, while non-moving-instance topologies usually replicate data volumes only unless application data resides on the boot volume, in which case separate synchronization may be required.

Preparing Oracle Databases For Full Stack Disaster Recovery

Oracle Base Database and supported Exadata databases require a Data Guard configuration with a standby in the intended recovery region; Full Stack DR supports only one Data Guard standby. Create vaults and secrets in both regions and store the database SYSDBA password in each secret for use when configuring database disaster recovery.

Preparing Oracle Autonomous Database Serverless For Full Stack Disaster Recovery

Autonomous Database Serverless requires a cross-region Autonomous Data Guard association with the standby database located in the intended recovery region. Same-region Autonomous Data Guard peer configurations are not supported by Full Stack DR.

Preparing Autonomous Database On Dedicated Exadata Infrastructure For Full Stack Disaster Recovery

Autonomous Database on Dedicated Exadata Infrastructure requires a cross-region Autonomous Data Guard association and a standby peer in the recovery region. Data Guard is configured and managed at the Autonomous Container Database level, so role transitions affect all Autonomous Databases hosted by that container.

Preparing Kubernetes Engine Oke For Disaster Recovery

OKE preparation requires a standby cluster, backup buckets in both regions, and replication for storage supporting persistent volumes. Configure standby load balancers for native ingress, replicate or copy Vault secrets when used, and prepare any jump host with Python 3, kubectl, Helm, PyYAML, and the OCI CLI for API access.

Preparing Integration Instance For Disaster Recovery

Oracle Integration 3 has native disaster recovery, while Full Stack DR can coordinate the integration instance with a broader protection configuration. Create the instance and enable its native cross-region disaster recovery before adding it to a DR protection group; Full Stack DR supports integration-instance switchover and failover.

Preparing MySQL Heatwave DB System For Disaster Recovery

MySQL HeatWave DR requires cross-region network connectivity, compatible security and routing rules, and optional SSL/TLS certificates. Create the primary system, make a manual backup, copy it to the standby region, restore a standby DB system, and create a replication channel from standby to primary; then change the standby database mode to read-only.

Preparing PostgreSQL DB System for Disaster Recovery

PostgreSQL DR requires appropriate IAM permissions, primary and standby systems running PostgreSQL 14 or later, and a warm-standby replica created in the recovery region. Configure network access, manually align database settings and extensions, verify primary and warm-standby roles, and monitor asynchronous replication. The standby is read-only, and its configuration is not automatically synchronized, so comparable system shapes and performance are recommended.

Preparing Applications For Full Stack Disaster Recovery

Application preparation involves identifying lifecycle scripts and commands for starting, stopping, and validating applications, determining whether they are stored locally or in Object Storage, and recording the user identities under which they must run. These details are required when customizing application recovery workflows.

Preparing Other Full Stack Disaster Recovery Workflow Customizations

Custom workflow preparation requires identifying scripts, commands, or Oracle Functions to execute and determining whether each is stored on compute instances, in Object Storage, or as serverless code. For local or Object Storage scripts, also specify the user identities that should execute them.

Creating Default NFS Client Export Option For File System

Configure NFS export options to permit clients from both primary and standby regions, using open access, subnet CIDR ranges, or specific IP addresses as appropriate. During file system switchover, Full Stack DR copies the primary export settings to the standby, enabling mounts on new standby compute addresses when the primary export configuration is correctly prepared.

Setting Up Policies For Full Stack Disaster Recovery And Other Services

Full Stack DR requires IAM policies that authorize the service and associated identities to manage protected OCI resources throughout disaster recovery operations. Configure the required policies in addition to preparing each resource type.

Preparing File System Mount Or Unmount On Windows Instance

Windows instances must grant the OCARUN service administrator rights, restart the service or instance, and verify the privilege using the Run Command plugin. File systems must be mounted under the SYSTEM user for successful unmount operations, and movable or non-movable instances require a designated mount script, such as a mount_nfs.cmd file stored in the specified ProgramData folder.