# Full Stack Disaster Recovery

This file contains the text from each Full Stack Disaster Recovery article landing page, release 22.

# Overview Of Full Stack Disaster Recovery

Learn about terminology, concepts, and benefits of Full Stack Disaster Recovery.

## About Full Stack Disaster Recovery

Full Stack Disaster Recovery (Full Stack DR) is an Oracle Cloud Infrastructure (OCI) service that offers comprehensive disaster recovery capabilities. It ensures business continuity by providing recovery for the entire application stack, including infrastructure, middleware, database, and applications. Full Stack DR integrates with various platforms and applications, generating and managing disaster recovery plans. It operates at the service level, allowing customization and active monitoring of recovery processes. The service includes prechecks for validating and monitoring business continuity readiness.

Read More: [About Full Stack Disaster Recovery](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/overview-of-full-stack-disaster-recovery/about-full-stack-disaster-recovery.html)

## Benefits Of Full Stack Disaster Recovery

Full Stack DR offers several advantages for business continuity. It provides full application recovery, intelligent plan generation, and minimizes disaster recovery time. The service validates DR workflows and configurations, reducing human errors. Additionally, it offers flexible and customizable DR workflows, eliminating the need for specialized skills. Full Stack DR provides a single pane of glass for monitoring and managing all disaster recovery needs, ensuring efficient and seamless operations.

Read More: [Benefits Of Full Stack Disaster Recovery](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/overview-of-full-stack-disaster-recovery/benefits-of-full-stack-disaster-recovery.html)

## Full Stack Disaster Recovery Terminology And Concepts

Before using Full Stack DR, understanding key terms is essential. Disaster Recovery (DR) refers to restoring business systems after an outage, with Recovery Point Objective (RPO) defining maximum data loss tolerance, and Recovery Time Objective (RTO) specifying the maximum downtime. Full Stack refers to all functional layers of an application. Primary and Standby roles indicate production and reserved versions, respectively. Warm and Cold Standby models balance operating costs and RTO. Resources are independently manageable OCI components, including DR Protection Groups, DR Plans, and DR Plan Executions. Associations define relationships between DR Protection Groups, while Plan Groups and Steps structure DR Plans. Prechecks validate DR Plan compliance, and Switchover and Failover plans perform planned and unplanned transitions, respectively. DR Drills test DR processes, and dependency mapping ensures correct system restoration order.
Read More: [Full Stack Disaster Recovery Terminology And Concepts](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/overview-of-full-stack-disaster-recovery/full-stack-disaster-recovery-terminology-and-concepts.html)


# 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.

Read More: [How Full Stack Disaster Recovery Works](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/get-started-with-full-stack-disaster-recovery/how-full-stack-disaster-recovery-works.html)

## 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.

Read More: [How To Access Full Stack Disaster Recovery](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/get-started-with-full-stack-disaster-recovery/how-to-access-full-stack-disaster-recovery.html)

## 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.

Read More: [Prerequisites For Full Stack Disaster Recovery](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/get-started-with-full-stack-disaster-recovery/prerequisites-for-full-stack-disaster-recovery.html)

## 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.

Read More: [Who Can Use Full Stack Disaster Recovery](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/get-started-with-full-stack-disaster-recovery/who-can-use-full-stack-disaster-recovery.html)

## 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.

Read More: [Preparing Log Location For Operation Logs](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/get-started-with-full-stack-disaster-recovery/preparing-log-location-for-operation-logs.html)

## 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.

Read More: [Preparing Compute Instances For Full Stack Disaster Recovery](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/get-started-with-full-stack-disaster-recovery/preparing-compute-instances-for-full-stack-disaster-recovery.html)

## 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.

Read More: [Preparing Object Storage For Full Stack Disaster Recovery](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/get-started-with-full-stack-disaster-recovery/preparing-object-storage-for-full-stack-disaster-recovery.html)

## 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.

Read More: [Preparing Block Storage For Full Stack Disaster Recovery](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/get-started-with-full-stack-disaster-recovery/preparing-block-storage-for-full-stack-disaster-recovery.html)

## 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.

Read More: [Preparing Oracle Databases For Full Stack Disaster Recovery](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/get-started-with-full-stack-disaster-recovery/preparing-oracle-databases-for-full-stack-disaster-recovery.html)

## 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.

Read More: [Preparing Oracle Autonomous Database Serverless For Full Stack Disaster Recovery](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/get-started-with-full-stack-disaster-recovery/preparing-oracle-autonomous-database-serverless-for-full-stack-disaster-recovery.html)

## 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.

Read More: [Preparing Autonomous Database On Dedicated Exadata Infrastructure For Full Stack Disaster Recovery](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/get-started-with-full-stack-disaster-recovery/preparing-autonomous-database-on-dedicated-exadata-infrastructure-for-full-stack-disaster-recovery.html)

## 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.

Read More: [Preparing Kubernetes Engine Oke For Disaster Recovery](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/get-started-with-full-stack-disaster-recovery/preparing-kubernetes-engine-oke-for-disaster-recovery.html)

## 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.

Read More: [Preparing Integration Instance For Disaster Recovery](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/get-started-with-full-stack-disaster-recovery/preparing-integration-instance-for-disaster-recovery.html)

## 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.

Read More: [Preparing MySQL Heatwave DB System For Disaster Recovery](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/get-started-with-full-stack-disaster-recovery/preparing-mysql-heatwave-db-system-for-disaster-recovery.html)

## 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.

Read More: [Preparing PostgreSQL DB System for Disaster Recovery](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/get-started-with-full-stack-disaster-recovery/preparing-postgresql-db-system-for-disaster-recovery.html)

## 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.

Read More: [Preparing Applications For Full Stack Disaster Recovery](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/get-started-with-full-stack-disaster-recovery/preparing-applications-for-full-stack-disaster-recovery.html)

## 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.

Read More: [Preparing Other Full Stack Disaster Recovery Workflow Customizations](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/get-started-with-full-stack-disaster-recovery/preparing-other-full-stack-disaster-recovery-workflow-customizations.html)

## 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.

Read More: [Creating Default NFS Client Export Option For File System](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/get-started-with-full-stack-disaster-recovery/creating-default-nfs-client-export-option-for-file-system.html)

## 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.

Read More: [Setting Up Policies For Full Stack Disaster Recovery And Other Services](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/get-started-with-full-stack-disaster-recovery/setting-up-policies-for-full-stack-disaster-recovery-and-other-services.html)

## 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.

Read More: [Preparing File System Mount Or Unmount On Windows Instance](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/get-started-with-full-stack-disaster-recovery/preparing-file-system-mount-or-unmount-on-windows-instance.html)


# Manage Disaster Recovery Protection Groups

## Overview Of Disaster Recovery Protection Groups

A Disaster Recovery Protection Group is a region-specific consistency group that coordinates recovery of complete application stacks by grouping OCI resources such as compute instances, volume groups, and databases. Each group pairs with exactly one peer, typically in another region or Availability Domain, while members may move between peer groups depending on the DR topology. The homepage provides table and region-map views showing group locations, associations, roles, and health.

Read More: [Overview Of Disaster Recovery Protection Groups](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-protection-groups/overview-of-disaster-recovery-protection-groups.html)

## View Region Maps Of Disaster Recovery Protection Groups

The region map provides a global view of subscribed regions and DR Protection Groups within a compartment. Region dots show configured groups, roles, counts, and health, while connecting lines identify associations between current and peer regions. Users can hover over regions or associations for summaries, click links to open group details, and zoom for additional role information.

Read More: [View Region Maps Of Disaster Recovery Protection Groups](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-protection-groups/view-region-maps-of-disaster-recovery-protection-groups.html)

## List Disaster Recovery Protection Groups

The DR Protection Groups page lists groups in a selected compartment and supports searching, filtering, sorting, and column management. Users can open group details or use row actions to copy the OCID, rename or move a group, manage tags, or delete it. The page also provides access to group creation and requires appropriate compartment permissions.

Read More: [List Disaster Recovery Protection Groups](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-protection-groups/list-disaster-recovery-protection-groups.html)

## Create Disaster Recovery Protection Groups

Create a DR Protection Group for each region participating in a disaster recovery plan by specifying its name and an Object Storage bucket for execution logs. Optionally assign a role, associate a peer group and region, and add members during creation or later. Required policies include permissions for Object Storage and tags.

Read More: [Create Disaster Recovery Protection Groups](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-protection-groups/create-disaster-recovery-protection-groups.html)

## View Disaster Recovery Protection Groups

A DR Protection Group details page displays the group’s role, peer association, plan information, plan executions, members, work requests, and the Object Storage location for execution logs. Users access these details by selecting a group from the list after choosing the appropriate compartment.

Read More: [View Disaster Recovery Protection Groups](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-protection-groups/view-disaster-recovery-protection-groups.html)

## Associate A Disaster Recovery Protection Group

A DR Protection Group can be associated with a peer only when its role is Not configured; an existing association must first be removed. From the group details page, select a role, peer region, and peer DR Protection Group, then confirm the association. The peer automatically receives the complementary role.

Read More: [Associate A Disaster Recovery Protection Group](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-protection-groups/associate-a-disaster-recovery-protection-group.html)

## Disassociate Disaster Recovery Protection Groups

Disassociating a Primary and Standby DR Protection Group permanently deletes their DR Plans, plan executions, and stored execution logs, requiring plans to be recreated. The group must already be associated and have a Primary or Standby role. The operation is initiated from the group details page and requires confirmation of the deletion warning.

Read More: [Disassociate Disaster Recovery Protection Groups](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-protection-groups/disassociate-disaster-recovery-protection-groups.html)

## Modify Disaster Recovery Protection Groups

A DR Protection Group can be modified by renaming it, adding or removing members, or moving it to another compartment. Changes to membership require all existing DR Plans to be refreshed and verified, and member changes may result in plan deletion depending on the modified properties.

Read More: [Modify Disaster Recovery Protection Groups](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-protection-groups/modify-disaster-recovery-protection-groups.html)

## Manage Members Of A Disaster Recovery Protection Group

Member management allows users to add, edit, or remove multiple resources and review each member’s service, compartment, automatic configuration, and modification state. Changes are published from the Members page after reviewing a summary and accepting the warning that membership changes delete existing plans. The updated plans must subsequently be refreshed and verified.

Read More: [Manage Members Of A Disaster Recovery Protection Group](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-protection-groups/manage-members-of-a-disaster-recovery-protection-group.html)

## Add Members To A Disaster Recovery Protection Group

Members are added from a DR Protection Group’s Members page by selecting a resource type and configuring its properties. Supported resources include compute instances, volume groups, load balancers, databases, file systems, Object Storage buckets, Autonomous Databases, OKE clusters, MySQL and PostgreSQL systems, and Integration instances. Resources should generally be added to the primary group, and membership changes require existing plans to be refreshed and verified.

Read More: [Add Members To A Disaster Recovery Protection Group](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-protection-groups/add-members-to-a-disaster-recovery-protection-group.html)

## Add A Compute Instance To A Disaster Recovery Protection Group

Compute instances can be added as moving or non-moving members, but instances attached to instance pools are unsupported. Moving instances relocate between peer groups during DR operations, while non-moving instances remain deployed in their regions and are started or stopped as needed. The selected model determines the additional network, storage, placement, and failover configuration required.

Read More: [Add A Compute Instance To A Disaster Recovery Protection Group](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-protection-groups/add-a-compute-instance-to-a-disaster-recovery-protection-group.html)

## Add A Moving Instance To A Disaster Recovery Protection Group

A moving instance is transferred to the peer group during DR operations and is typically used in Pilot Light topologies. Configuration requires VNIC mappings for every interface, including destination VCNs, subnets, optional reserved addresses, security groups, and applicable host settings. Users can also configure fault-domain retention, destination compartments, dedicated hosts or capacity reservations, file-system mappings, and drill-specific VNIC mappings; all destination prerequisites must exist before plan creation.

Read More: [Add A Moving Instance To A Disaster Recovery Protection Group](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-protection-groups/add-a-moving-instance-to-a-disaster-recovery-protection-group.html)

## Add A Non-Moving Instance To A Disaster Recovery Protection Group

A non-moving instance remains in its deployed region and is used in Active-Passive configurations where instances are pre-deployed in both regions. Optional settings control starting and stopping during failover, while block-volume mappings, peer reference instances, mount points, and file-system export mappings define storage handling. Storage must be configured consistently in both regions, and plan refresh and verification are required after membership changes.

Read More: [Add A Non-Moving Instance To A Disaster Recovery Protection Group](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-protection-groups/add-a-non-moving-instance-to-a-disaster-recovery-protection-group.html)

## Add A Volume Group To A Disaster Recovery Protection Group

Adding a volume group requires selecting its destination compartment, an existing destination backup policy, and an encryption strategy. Volumes may retain default encryption, use one common customer-managed key, or use individual destination vault keys for each volume. The volume group should be added to the primary group, and existing plans must be refreshed and verified after the change.

Read More: [Add A Volume Group To A Disaster Recovery Protection Group](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-protection-groups/add-a-volume-group-to-a-disaster-recovery-protection-group.html)

## Add A Load Balancer Or A Network Load Balancer To A Disaster Recovery Protection Group

A load balancer or network load balancer must have corresponding primary and standby resources and mapped source and destination backend sets. Configure separate backend sets for moving and non-moving instances, marking non-moving sets so traffic is controlled during DR operations; moving-instance sets should remain unmarked and use appropriate backend IP mappings. Add the resource to the primary group and refresh and verify plans after the change.

Read More: [Add A Load Balancer Or A Network Load Balancer To A Disaster Recovery Protection Group](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-protection-groups/add-a-load-balancer-or-a-network-load-balancer-to-a-disaster-recovery-protection-group.html)

## Add An Oracle Database To A Disaster Recovery Protection Group

Supported Oracle members include Base Database Service, Exadata on Dedicated or Exascale Infrastructure, Exadata Cloud@Customer, and Exadata on Oracle Public Cloud. Adding a database requires selecting its hosting system or cluster, database home where applicable, database, and a Vault secret containing its password. Primary and standby databases must be added to their corresponding groups, and passwords are retrieved only during DR operations rather than stored by the service.

Read More: [Add An Oracle Database To A Disaster Recovery Protection Group](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-protection-groups/add-an-oracle-database-to-a-disaster-recovery-protection-group.html)

## Add A File System To A Disaster Recovery Protection Group

Before adding a file system, create the file system, replication, security rules, and both DR groups. Configure the destination compartment and Availability Domain, source-to-destination export mappings, and destination snapshot policy, vault, and encryption key. Replication and encryption resources must already exist in the destination region, and file systems should not be shared with compute members from unrelated DR groups.

Read More: [Add A File System To A Disaster Recovery Protection Group](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-protection-groups/add-a-file-system-to-a-disaster-recovery-protection-group.html)

## Add An Object Storage Bucket To A Dr Protection Group

Add an Object Storage bucket by selecting the resource type and the desired bucket, then accepting the plan-refresh warning and confirming the addition. Buckets should be added to the primary DR Protection Group, and existing plans require refresh and verification after the membership change.

Read More: [Add An Object Storage Bucket To A Dr Protection Group](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-protection-groups/add-an-object-storage-bucket-to-a-dr-protection-group.html)

## Add An Autonomous Database Serverless To A Disaster Recovery Protection Group

Add an Autonomous AI Database Serverless by selecting the database and a DR drill standby type: refreshable clone, full clone, or snapshot standby. Full clones additionally require a database password secret and destination encryption settings. Only Start drill and Stop drill plans are currently supported, and membership changes require plan refresh and verification.

Read More: [Add An Autonomous Database Serverless To A Disaster Recovery Protection Group](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-protection-groups/add-an-autonomous-database-serverless-to-a-disaster-recovery-protection-group.html)

## Add An Autonomous Database On Dedicated Exadata Infrastructure To A Disaster Recovery Protection Group

Add an Autonomous container database hosted on dedicated infrastructure or Exadata Cloud@Customer, then select the connection-string behavior for drills. Primary service reuses the primary connection strings for snapshot standby, while Snapshot service creates new standby connection strings. The resource belongs in the primary group, and existing plans must be refreshed and verified after addition.

Read More: [Add An Autonomous Database On Dedicated Exadata Infrastructure To A Disaster Recovery Protection Group](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-protection-groups/add-an-autonomous-database-on-dedicated-exadata-infrastructure-to-a-disaster-recovery-protection-group.html)

## Add An OKE Cluster To A Disaster Recovery Protection Group

Adding an OKE cluster supports backup scheduling, retention, private OCIR image replication, namespace selection, peer-cluster association, node-pool scaling, jump-host access, load-balancer and Vault mappings, and Kubernetes resource modifiers. Backup schedules can be hourly, daily, weekly, or monthly, while namespaces may be included or excluded selectively. Destination resources, secrets, and access prerequisites must be configured, and plans require refresh and verification after adding the cluster.

Read More: [Add An OKE Cluster To A Disaster Recovery Protection Group](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-protection-groups/add-an-oke-cluster-to-a-disaster-recovery-protection-group.html)

## Add A MySQL DB System To A Disaster Recovery Protection Group

Add a MySQL DB System by selecting the system, peer system, reconciliation timeout behavior, administrator credentials, and replication credentials stored in Vault secrets. The peer option requires an associated group or selected peer region, and the timeout continuation setting determines whether DR proceeds after reconciliation exceeds the configured limit. Existing plans must be refreshed and verified after addition.

Read More: [Add A MySQL DB System To A Disaster Recovery Protection Group](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-protection-groups/add-a-mysql-db-system-to-a-disaster-recovery-protection-group.html)

## Add a PostgreSQL DB System to a Disaster Recovery Protection Group

Before adding a PostgreSQL DB System, ensure its warm standby is configured and replication is healthy. Select the primary or standby system and its corresponding peer, add the member, and publish the updated group configuration. The primary group must reference the primary system and warm standby, while the standby group uses the reverse relationship.

Read More: [Add a PostgreSQL DB System to a Disaster Recovery Protection Group](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-protection-groups/add-a-postgresql-db-system-to-a-disaster-recovery-protection-group.html)

## Add An Integration Instance To A Disaster Recovery Protection Group

Add an Integration instance by selecting it from Developer Services and confirming the membership change. Oracle Integration instances must be added to both primary and standby groups, and Oracle Managed Disaster Recovery must be enabled in Oracle Integration 3 before the instances are registered with Full Stack DR.

Read More: [Add An Integration Instance To A Disaster Recovery Protection Group](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-protection-groups/add-an-integration-instance-to-a-disaster-recovery-protection-group.html)

## Delete Members From A Disaster Recovery Protection Group

Members can be removed individually through a member’s Action menu or in bulk by selecting multiple members and choosing Remove members. Each removal requires confirmation because existing DR Plans must be refreshed and verified afterward. The removal is completed from the group’s Members and Manage members pages.

Read More: [Delete Members From A Disaster Recovery Protection Group](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-protection-groups/delete-members-from-a-disaster-recovery-protection-group.html)

## Edit Member Properties For A Disaster Recovery Protection Group

Existing member properties are edited from the Manage members page by opening the member’s Action menu, changing the configuration, and selecting Update. Editing member properties requires all affected DR Plans to be refreshed, and the group and member must be accessed through the appropriate compartment.

Read More: [Edit Member Properties For A Disaster Recovery Protection Group](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-protection-groups/edit-member-properties-for-a-disaster-recovery-protection-group.html)

## Update Disaster Recovery Protection Group Role

A paired DR Protection Group’s role can be changed between Primary and Standby from its information pane. The peer role updates automatically, plans in the former primary become Inactive, and plans in the new primary become Active. Role changes require an existing peer association and cannot be performed on an unassociated Not configured group.

Read More: [Update Disaster Recovery Protection Group Role](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-protection-groups/update-disaster-recovery-protection-group-role.html)

## Delete A Disaster Recovery Protection Group

To delete a DR Protection Group, first ensure it has the Not configured role by disassociating it from any peer. From the group details page, select Delete and confirm the operation. The group enters Deleted state, is eventually removed, and cannot be used afterward.

Read More: [Delete A Disaster Recovery Protection Group](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-protection-groups/delete-a-disaster-recovery-protection-group.html)

## Rename A Disaster Recovery Protection Group

Rename a DR Protection Group from its details page by selecting Rename, entering the new name, and saving the change. The operation requires selecting the group from the appropriate compartment on the DR Protection Groups list.

Read More: [Rename A Disaster Recovery Protection Group](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-protection-groups/rename-a-disaster-recovery-protection-group.html)


# Manage Disaster Recovery Plans

## Overview Of Disaster Recovery Plans

A Disaster Recovery plan is an automated Full Stack DR runbook that transitions application resources between associated primary and standby protection groups. Plans contain sequential plan groups with parallel steps, are automatically generated through resource introspection, and can be customized with user-defined groups, steps, ordering, and execution settings. Plans are created only at the standby protection group, where they are Active; plans at the primary group are Inactive and become Active when roles reverse after a transition.

Read More: [Overview Of Disaster Recovery Plans](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plans/overview-of-disaster-recovery-plans.html)

## Types Of Disaster Recovery Plans

Full Stack DR supports failover plans for unplanned outages, switchover plans for orderly planned transitions, and start and stop drill plans for testing standby recovery without disrupting production. Failover requires availability in the standby region, while switchover requires both regions to be available. During a drill, protection groups enter DrillInProgress, normal plan operations and membership changes are restricted, roles remain unchanged, and only a stop drill can restore Active operation.

Read More: [Types Of Disaster Recovery Plans](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plans/types-of-disaster-recovery-plans.html)

## Create A Disaster Recovery Plan

Create a DR plan from the Plans section of an associated DR protection group that currently has the standby role. Open the creation dialog, provide a plan name, select the plan type, and create the plan.

Read More: [Create A Disaster Recovery Plan](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plans/create-a-disaster-recovery-plan.html)

## View A Disaster Recovery Plan

View a DR plan by opening the Plans section for its protection group and selecting the plan name. The details page displays plan groups in execution order; expand a group to inspect its individual steps.

Read More: [View A Disaster Recovery Plan](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plans/view-a-disaster-recovery-plan.html)

## Modify A Disaster Recovery Plan

Full Stack DR generates built-in groups and steps automatically, while users can add and customize user-defined groups and steps, rename plans, change execution settings, clone plans, reorder content, and remove user-defined elements. Built-in groups and steps cannot be deleted but can be disabled. Plans affected by protection-group changes must be refreshed and verified before reuse, and API updates must include the complete group and step structure.

Read More: [Modify A Disaster Recovery Plan](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plans/modify-a-disaster-recovery-plan.html)

## Rename A Disaster Recovery Plan

Rename a DR plan from either its Actions menu in the Plans list or the plan details page. Enter the new name in the rename dialog and save the change.

Read More: [Rename A Disaster Recovery Plan](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plans/rename-a-disaster-recovery-plan.html)

## Edit Attributes Of A Plan Group

Plan-group attributes can be edited from the group Actions menu on the plan details page. Supported changes include renaming the group, enabling or disabling all steps, changing step timeouts, and changing error modes; save each modification to apply it.

Read More: [Edit Attributes Of A Plan Group](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plans/edit-attributes-of-a-plan-group.html)

## Edit Attributes Of Steps In A Plan Group

Edit an individual step from its expanded plan group and Actions menu. You can change the step name, choose whether execution stops or continues after an error, set the timeout, and enable or disable execution; built-in steps require a timeout of at least 600 seconds.

Read More: [Edit Attributes Of Steps In A Plan Group](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plans/edit-attributes-of-steps-in-a-plan-group.html)

## Clone A Disaster Recovery Plan

Clone a DR plan from its Actions menu by supplying a new name and confirming the operation. The resulting plan is labeled Clone and identifies its source plan; inactive or deleted plans cannot be cloned.

Read More: [Clone A Disaster Recovery Plan](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plans/clone-a-disaster-recovery-plan.html)

## Refresh A Disaster Recovery Plan

Changes to either protection group place affected plans into Needs attention with a Needs refresh sub-state, requiring a refresh followed by verification. Refresh the eligible plan from its details page, inspect added, modified, or deleted groups and steps, and verify the result before use. Inactive plans with Needs refresh cannot be refreshed, and plans cannot be edited during verification.

Read More: [Refresh A Disaster Recovery Plan](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plans/refresh-a-disaster-recovery-plan.html)

## Understanding The Dr Plan Refresh Process

Refreshing a plan reconciles its groups and steps with current protection-group membership. New members add steps to matching groups or create new groups, while removed members delete corresponding steps and, when applicable, entire groups and related user-defined steps. New groups are inserted according to the default order when possible, though extensive custom reordering may affect placement. Plans in Active or refresh-related states return to Needs attention with Needs refresh whenever the protection group changes.

Read More: [Understanding The Dr Plan Refresh Process](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plans/understanding-the-dr-plan-refresh-process.html)

## Verify A Disaster Recovery Plan

After every plan refresh, review the updated groups, steps, and execution order, then select Verify to finalize the changes. Verification removes items marked for deletion, incorporates added items, and returns the plan to usable status; it remains required even when no visible changes result from the refresh.

Read More: [Verify A Disaster Recovery Plan](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plans/verify-a-disaster-recovery-plan.html)

## Manage Plan Groups

The Manage plan groups interface supports adding, editing, renaming, removing, and publishing user-defined groups and steps. It tracks modifications as Added, Modified, or Removed and allows changes to timeouts, error modes, and group names. Built-in and built-in precheck groups cannot be deleted, although empty built-in groups may be disabled; publish commits the changes, while cancel discards them.

Read More: [Manage Plan Groups](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plans/manage-plan-groups.html)

## Add User-Defined Plan Groups And Steps

Add user-defined groups or steps through Manage plan groups, positioning new groups before or after an existing group but always after Built In Prechecks. Configure the step name, enabled state, error mode, timeout, execution region, and execution method using an Object Storage script, local script, or Oracle Function. User-defined steps run through Cloud Agent Run Command on instances or through Functions, and failover function steps must use the standby region.

Read More: [Add User-Defined Plan Groups And Steps](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plans/add-user-defined-plan-groups-and-steps.html)

## Configure A Step To Execute An Object Storage Script

Configure an Object Storage script step by selecting the instance region, target instance, bucket, and script or archive, then specifying the command and parameters, timeout, optional Linux run-as user, and enabled state. The object or archive must be in the standby region, the selected region must match the instance’s current location, private instances require suitable network access, and nonzero script exit codes fail the step.

Read More: [Configure A Step To Execute An Object Storage Script](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plans/configure-a-step-to-execute-an-object-storage-script.html)

## Configure A Step To Execute A Local Script

Configure a local script step by selecting the instance’s current region, compartment, target instance, script, full command and parameters, timeout, optional Linux run-as user, and enabled state. Nonzero exit codes fail the step; for movable instances, place the step after the plan group that launches the instance in the standby region.

Read More: [Configure A Step To Execute A Local Script](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plans/configure-a-step-to-execute-a-local-script.html)

## Configure A Step To Execute Oracle Functions

Configure a serverless user-defined step by selecting the Functions region, choosing Invoke function, selecting the target application and function, optionally supplying a payload, and adding the step.

Read More: [Configure A Step To Execute Oracle Functions](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plans/configure-a-step-to-execute-oracle-functions.html)

## Add User-Defined Precheck

User-defined prechecks can be added to an existing built-in precheck group when the plan contains at least one built-in or user-defined group. Configure the step using an instance script, Object Storage script, or Function, along with its region, target resources, error mode, timeout, and enabled state. Built-in and user-defined prechecks execute in parallel during both standalone prechecks and plan execution.

Read More: [Add User-Defined Precheck](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plans/add-user-defined-precheck.html)

## Add A Pause Group In A Plan Group

Add a pause group through Manage plan groups to suspend plan execution at a selected position. Provide a group name, enable or disable the pause, and place it before or after an eligible group; pauses cannot be placed before Built In Prechecks or after the final group. Pause groups can later be edited, enabled, disabled, or resumed.

Read More: [Add A Pause Group In A Plan Group](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plans/add-a-pause-group-in-a-plan-group.html)

## Reorder Groups And Steps

Full Stack DR organizes steps into dependency-based built-in groups, but users can reorder groups and move steps into other built-in or user-defined groups. Such customization must preserve resource dependencies and execution order to ensure that recovery operations occur correctly.

Read More: [Reorder Groups And Steps](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plans/reorder-groups-and-steps.html)

## Change The Order Of Plan Groups

Reorder plan groups from the standby protection group’s plan editor using Move up and Move down, then publish and save the changes. Built In Prechecks must remain first, and reordering built-in groups is discouraged because their generated order reflects recovery dependencies; user-defined groups are the safer candidates for rearrangement.

Read More: [Change The Order Of Plan Groups](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plans/change-the-order-of-plan-groups.html)

## Move Selected Steps To Another Plan Group

Move steps through the plan editor by selecting a source step, choosing a target group, and updating the proposed arrangement. Steps in the same group execute in parallel, so dependent steps must remain in groups that run later than their prerequisites. Changes can be reverted or repeated before publishing the final arrangement.

Read More: [Move Selected Steps To Another Plan Group](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plans/move-selected-steps-to-another-plan-group.html)

## Remove User-Defined Plan Groups

Remove a user-defined plan group from its Actions menu on the plan details page, then confirm the removal. Built-in groups are not eligible for deletion through this operation.

Read More: [Remove User-Defined Plan Groups](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plans/remove-user-defined-plan-groups.html)

## Remove User-Defined Steps From A Plan Group

Remove a user-defined step by expanding its plan group, opening the step’s Actions menu, selecting Remove, and confirming the operation.

Read More: [Remove User-Defined Steps From A Plan Group](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plans/remove-user-defined-steps-from-a-plan-group.html)

## Delete A Disaster Recovery Plan

Delete a DR plan from its Actions menu in the Plans list and confirm the deletion. The plan enters the Deleted state, is later removed, and cannot be used once deleted.

Read More: [Delete A Disaster Recovery Plan](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plans/delete-a-disaster-recovery-plan.html)


# Manage Disaster Recovery Plan Executions

## Overview Of Disaster Recovery Plan Executions

A Disaster Recovery plan execution runs plan groups sequentially while executing steps within each group in parallel, applying configured attributes such as error mode, timeout, and enabled status. Prechecks passively validate plan steps and associated members without changing the DR topology, either independently or immediately before execution. Regular stand-alone prechecks help maintain readiness, while built-in prechecks validate a plan before launch. Only one precheck or execution can run for a protection-group pair at a time, during which the groups remain in the Updating state and cannot be modified.

Read More: [Overview Of Disaster Recovery Plan Executions](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plan-executions/overview-of-disaster-recovery-plan-executions.html)

## Create Disaster Recovery Plan Executions

To manually start a DR plan execution, open the standby DR protection group, navigate to Plans, select Execute DR plan, optionally enable prechecks and configure whether warnings should be ignored, provide an optional execution name, and start the execution. Ignoring warnings allows completion with a Partially succeeded status; otherwise, warnings cause failure. Resources created during switchover or failover retain the original resource names with an added free-form tag.

Read More: [Create Disaster Recovery Plan Executions](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plan-executions/create-disaster-recovery-plan-executions.html)

## Prechecks For Disaster Recovery Plan Executions

Run Precheck validates all steps and associated members in a DR plan without modifying the environment. From the standby DR protection group’s Plans page, select Run Prechecks, configure whether warnings should be ignored, optionally name the precheck, and start it. With warnings ignored, affected steps are marked Succeeded; otherwise, they are marked Partially Succeeded.

Read More: [Prechecks For Disaster Recovery Plan Executions](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plan-executions/prechecks-for-disaster-recovery-plan-executions.html)

## Monitor Disaster Recovery Plan Executions

DR plan execution monitoring provides access to execution progress, detailed logs, step statuses, and AI-generated summaries for failed or warning steps. Users can monitor prechecks and plan executions, inspect group and step results, download logs, and review troubleshooting summaries. The available monitoring functions include progress tracking, log viewing, step-status inspection, and summary-log review.

Read More: [Monitor Disaster Recovery Plan Executions](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plan-executions/monitor-disaster-recovery-plan-executions.html)

## Monitor Progress Of Disaster Recovery Plan Executions

The Plan Executions page lists all executions and prechecks, with the active operation shown first in the In Progress state. Opening it displays plan groups and their statuses: Queued, In Progress, Succeeded, Partially succeeded, or Failed. Groups execute sequentially, and expanding a group reveals step details. Automatically triggered executions also show event information, such as the triggering event and related member OCID.

Read More: [Monitor Progress Of Disaster Recovery Plan Executions](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plan-executions/monitor-progress-of-disaster-recovery-plan-executions.html)

## View Logs For Disaster Recovery Plan Executions

Execution logs can be viewed from a plan execution’s resource page by expanding a plan group, opening a step’s Action menu, and selecting View log; logs can also be downloaded directly. The console displays only the final 1 KB of a step log when the log exceeds that limit, so downloading the log is required to review its complete contents.

Read More: [View Logs For Disaster Recovery Plan Executions](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plan-executions/view-logs-for-disaster-recovery-plan-executions.html)

## View Step Status For Disaster Recovery Plan Executions

The execution Details page summarizes step counts and statuses, including Success, Pending, Warning, Failed, and Skipped. Selecting View details opens the Step status page, which categorizes successful, pending, warning, failed, and skipped steps and shows relevant counts, including the number of ignored warnings.

Read More: [View Step Status For Disaster Recovery Plan Executions](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plan-executions/view-step-status-for-disaster-recovery-plan-executions.html)

## View Summary Logs For Disaster Recovery Plan Executions

OCI Full Stack Disaster Recovery can generate AI summaries of logs for eligible built-in and built-in precheck steps ending in Failed, Failed ignored, or Succeeded with warning. Summaries identify the problem, suggest solutions, and list reference identifiers, using OCI Generative AI and requiring appropriate IAM policies, supported regional availability, and applicable service charges. The feature does not support user-defined steps; summaries should be validated against the full logs because they are troubleshooting aids and may contain errors.

Read More: [View Summary Logs For Disaster Recovery Plan Executions](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plan-executions/view-summary-logs-for-disaster-recovery-plan-executions.html)

## Pause A Disaster Recovery Plan Execution

Only in-progress DR plan executions can be paused; prechecks cannot be paused. From the standby protection group’s Plan Executions page, open the active execution and select Pause. The execution pauses after the currently running group finishes, while the DR protection group remains in the Updating state.

Read More: [Pause A Disaster Recovery Plan Execution](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plan-executions/pause-a-disaster-recovery-plan-execution.html)

## Resume A Disaster Recovery Plan Execution

Only paused DR plan executions can be resumed, and prechecks cannot be paused or resumed. From the standby protection group’s Plan Executions page, open the paused execution and select Resume. The execution returns to In Progress, resumes with the next queued group, and leaves the protection group in the Updating state during continuation.

Read More: [Resume A Disaster Recovery Plan Execution](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plan-executions/resume-a-disaster-recovery-plan-execution.html)

## Cancel A Disaster Recovery Plan Execution

An in-progress or paused DR plan execution can be canceled, but it cannot later be resumed or retried. Cancellation takes effect after the active group finishes and may leave application components or the DR topology inconsistent. The protection group enters Needs attention and may require manual recovery and a separate Reset State operation for each protection group in the pair to return it to Active.

Read More: [Cancel A Disaster Recovery Plan Execution](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plan-executions/cancel-a-disaster-recovery-plan-execution.html)

## Retry A Group In Disaster Recovery Plan Execution

A failed DR plan execution or precheck allows retrying a failed plan group. From the failed execution, identify the group marked Failed, open its Action menu, and select Retry. All failed steps in that group are rerun, after which the plan execution resumes.

Read More: [Retry A Group In Disaster Recovery Plan Execution](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plan-executions/retry-a-group-in-disaster-recovery-plan-execution.html)

## Retry A Step In Disaster Recovery Plan Execution

A failed step can be retried when its DR plan execution or precheck is in the Failed state. Open the failed execution, expand the failed group, locate the failed step, and select Retry from its Action menu. The execution resumes by rerunning that step.

Read More: [Retry A Step In Disaster Recovery Plan Execution](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plan-executions/retry-a-step-in-disaster-recovery-plan-execution.html)

## Skip A Step In Disaster Recovery Plan Execution

A failed step in a DR plan execution can be skipped when the execution is Failed, allowing the plan to resume without rerunning that step. From the failed execution, expand the failed group, open the failed step’s Action menu, and select Skip. Failed precheck steps cannot be skipped; the entire precheck must be rerun instead.

Read More: [Skip A Step In Disaster Recovery Plan Execution](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plan-executions/skip-a-step-in-disaster-recovery-plan-execution.html)

## Skip A Group In Disaster Recovery Plan Execution

A failed group can be skipped when a DR plan execution or precheck is in the Failed state. Open the failed execution, locate the failed group, and select Skip from its Action menu. All steps in that group are bypassed, and execution resumes with the group that follows it.

Read More: [Skip A Group In Disaster Recovery Plan Execution](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plan-executions/skip-a-group-in-disaster-recovery-plan-execution.html)

## Delete Disaster Recovery Plan Executions

DR plan executions can be deleted only in terminal Succeeded or Canceled states; failed executions must first be canceled. From the Plan Executions page, use the execution’s Action menu or its details-page Actions menu, select Delete, and confirm. Deletion removes the execution and associated logs, changes it to Deleted, and eventually removes it from view and makes it unusable.
Read More: [Delete Disaster Recovery Plan Executions](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-disaster-recovery-plan-executions/delete-disaster-recovery-plan-executions.html)


# Manage and Configure Automatic DR Configuration

## Manage Automatic DR Configuration

Full Stack Disaster Recovery supports automatic execution of Switchover and Failover DR Plans through one Automatic DR Configuration per DR Protection Group. The configuration is created on the standby DR Protection Group, identifies database members and their triggering operations, and requires Resource Principal policies so the service can execute plans without user credentials.

Read More: [Manage Automatic DR Configuration](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-and-configure-automatic-dr-configuration/manage-automatic-dr-configuration.html)

## Configure Automatic Dr Plan Execution

To configure automatic DR execution, create an Automatic DR Configuration on an active standby DR Protection Group, select default switchover and failover plans, add supported Data Guard database members, and enable at least one triggering operation per member. The configuration is subject to role, lifecycle, membership, plan-state, supported-member, uniqueness, and Resource Principal policy validations; after a switchover or failover, the configuration on the new primary becomes inactive and must be recreated on the new standby.

Read More: [Configure Automatic Dr Plan Execution](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-and-configure-automatic-dr-configuration/configure-automatic-dr-plan-execution.html)

## Custom Audit Events For Automatic Dr Execution

Automatic DR execution emits custom audit events in the Automatic DR Configuration’s compartment to report processing status. Rejected events indicate role, member subscription, or operation mismatches; successful events confirm submission but not execution completion; failed events indicate validation or inactive resource conditions; and skipped events indicate that another DR execution is already in progress for the same DR Protection Group.
Read More: [Custom Audit Events For Automatic Dr Execution](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/manage-and-configure-automatic-dr-configuration/custom-audit-events-for-automatic-dr-execution.html)


# Policies

## Resource Principals

Configure resource principal authentication for Full Stack Disaster Recovery by creating a dynamic group with matching rules for DR protection groups, compute instances, and compute container instances, then assigning IAM policies for DR and the OCI services managed during recovery. Required permissions vary by member type and can include disaster recovery, compute, storage, networking, databases, OKE, load balancer, Vault, Functions, Integration, tagging, and Object Storage access; replace placeholder dynamic-group and compartment values with actual identifiers.

Read More: [Resource Principals](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/policies/resource-principals.html)

## Policies For Full Stack Disaster Recovery

This chapter defines the IAM policies required for Full Stack Disaster Recovery, covering policy concepts, resource types and permissions, REST API operation requirements, cumulative access levels for inspect, read, use, and manage verbs, and example policies for administering DR operations, configurations, and prechecks.

Read More: [Policies For Full Stack Disaster Recovery](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/policies/policies-for-full-stack-disaster-recovery.html)

## About IAM Policies For Disaster Recovery

IAM policies for Disaster Recovery can target individual resource types or the complete disaster-recovery-family. The family includes protection groups, plans, plan prechecks, plan executions, and work requests, allowing administrators to choose either granular or family-wide access controls.

Read More: [About IAM Policies For Disaster Recovery](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/policies/about-iam-policies-for-disaster-recovery.html)

## Resource Types And Permissions

This page lists the permissions associated with each Full Stack Disaster Recovery resource type, including protection groups, plans, prechecks, executions, work requests, and the aggregate disaster-recovery-family. Permissions cover inspection, reading, creation, updates, deletion, and work-request monitoring.

Read More: [Resource Types And Permissions](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/policies/resource-types-and-permissions.html)

## Permissions For REST API Operations

Full Stack DR REST API operations require specific IAM permissions, with some operations accepting alternative permissions. The mappings cover creating, reading, updating, deleting, pausing, resuming, retrying, or canceling DR plans and executions, managing protection groups, and inspecting or controlling work requests.

Read More: [Permissions For REST API Operations](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/policies/permissions-for-rest-api-operations.html)

## Details Of Verb And Resource-Type Combinations

Access is cumulative across the inspect, read, use, and manage verbs. The page maps each verb to incremental permissions and REST APIs for protection groups, DR plans, plan executions, prechecks, and work requests, clarifying which operations become available at each access level.

Read More: [Details Of Verb And Resource-Type Combinations](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/policies/details-of-verb-and-resource-type-combinations.html)

## Examples Of IAM Policy Definitions For Disaster Recovery

Example policies demonstrate how to grant tenancy-wide DR administration, compartment-scoped configuration and precheck execution, or configuration-only access. The examples use separate groups to illustrate full administration, monitored DR setup, and limited creation of protection groups and plans.

Read More: [Examples Of IAM Policy Definitions For Disaster Recovery](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/policies/examples-of-iam-policy-definitions-for-disaster-recovery.html)

## Policies For Other Services Managed By Full Stack Disaster Recovery

Because Full Stack DR orchestrates resources across the application stack, additional IAM policies are required for services such as Compute, Block Volume, Networking, Functions, databases, Autonomous Database, Object Storage, Tags, Vault, File Systems, load balancers, OKE, MySQL, PostgreSQL, compartments, Automatic DR, Integration, and Generative AI. The required policies depend on the selected member types and authentication method.

Read More: [Policies For Other Services Managed By Full Stack Disaster Recovery](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/policies/policies-for-other-services-managed-by-full-stack-disaster-recovery.html)

## Policies For Compute Service And Oracle Cloud Agent

DR requires Compute and Oracle Cloud Agent permissions to manage movable and non-movable instances, volumes, networking, capacity reservations, images, and agent commands. Resource principal configurations use dynamic groups, while user authentication uses group policies; Oracle Cloud Agent also requires instance membership in a dynamic group and administrator privileges for command execution.

Read More: [Policies For Compute Service And Oracle Cloud Agent](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/policies/policies-for-compute-service-and-oracle-cloud-agent.html)

## Policies For Block Volume Service

Block Volume and volume group recovery requires permissions to manage the volume family and read Vaults and secrets when resource principal authentication is used. Equivalent user-authenticated policies grant the appropriate group access to volume resources, Vaults, and secrets within the target compartment.

Read More: [Policies For Block Volume Service](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/policies/policies-for-block-volume-service.html)

## Policies For Networking Service

Networking policies allow Full Stack DR to inspect virtual networking and use subnets, VNICs, network security groups, and private IPs. Equivalent resource principal and user-authenticated statements can be scoped to the compartment containing the application networking resources.

Read More: [Policies For Networking Service](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/policies/policies-for-networking-service.html)

## Policies For Functions Service

To invoke Functions from user-defined DR plan steps, the DR principal or user group must read the target application and function and use Function invocation permissions in the relevant compartment.

Read More: [Policies For Functions Service](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/policies/policies-for-functions-service.html)

## Policies For Oracle Database

Oracle Base Database and Exadata database recovery requires permissions to manage databases and read Vaults and secrets when using resource principals. User-based policies can grant full database-family management or restrict access to update operations for switchover and failover, with additional permissions for database homes, Data Guard associations, and supported VM cluster types.

Read More: [Policies For Oracle Database](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/policies/policies-for-oracle-database.html)

## Policies For Oracle Autonomous Database

Autonomous Database recovery requires resource principals to manage the autonomous database family, read Vaults and secrets, and manage Autonomous Container Databases where applicable. User policies can provide full management or restrict access to update and Data Guard operations for Serverless and dedicated Exadata deployments.

Read More: [Policies For Oracle Autonomous Database](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/policies/policies-for-oracle-autonomous-database.html)

## Policies For Log Location For Operation Logs

Full Stack DR needs Object Storage bucket and object management permissions to write operation logs during DR plan executions. The same bucket and object permissions can be granted either to the DR dynamic group or to a user group in the selected compartment.

Read More: [Policies For Log Location For Operation Logs](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/policies/policies-for-log-location-for-operation-logs.html)

## Policies For Object Storage

Object Storage policies allow DR to manage buckets that participate in a DR protection group and to write execution logs. Resource principals use object-family management permissions, while user authentication grants equivalent permissions to a designated group.

Read More: [Policies For Object Storage](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/policies/policies-for-object-storage.html)

## Policies For Tags Service

DR requires permission to use tag namespaces when launching compute instances during plan execution. This access can be granted to the resource principal dynamic group or a user group at the tenancy level.

Read More: [Policies For Tags Service](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/policies/policies-for-tags-service.html)

## Policies For Vault Service

Vault policies allow DR to read Vaults and secrets, enabling retrieval of database credentials required during plan executions. Equivalent permissions can be assigned to the DR dynamic group or an authenticated user group within the relevant compartment.

Read More: [Policies For Vault Service](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/policies/policies-for-vault-service.html)

## Policies For File Systems

File system recovery requires resource principals to manage the file-family and read Vaults and secrets where credential access is needed. User authentication requires the designated group to manage the file-family in the target compartment.

Read More: [Policies For File Systems](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/policies/policies-for-file-systems.html)

## Policies For Load Balancers

DR load balancer management requires the dynamic group or authenticated user group to manage load-balancers in the compartment containing the application’s load balancers.

Read More: [Policies For Load Balancers](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/policies/policies-for-load-balancers.html)

## Policies For Kubernetes Engine (OKE)

OKE recovery requires permissions to manage compute containers, Object Storage, clusters, and virtual node pools. Additional workload identity policies support Brie service accounts for virtual node pools, while managed node pools, container instances, and jump hosts require suitable dynamic groups and policies for cluster and bucket access.

Read More: [Policies For Kubernetes Engine (OKE)](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/policies/policies-for-kubernetes-engine-oke.html)

## Policies For MySQL Heatwave DB System

MySQL HeatWave recovery requires management of the MySQL resource family and, when needed, read access to Vault secrets and Object Storage for credentials and execution logs. Policies can be assigned to resource principals through dynamic groups or to user groups, with compartment-specific scoping.

Read More: [Policies For MySQL Heatwave DB System](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/policies/policies-for-mysql-heatwave-db-system.html)

## Policies for PostgreSQL DB System

PostgreSQL recovery requires the dynamic group to manage PostgreSQL DB systems, backups, configurations, and work requests in the target compartment.

Read More: [Policies for PostgreSQL DB System](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/policies/policies-for-postgresql-db-system.html)

## Policies For Network Load Balancers

Network load balancer recovery requires the resource principal dynamic group or authenticated user group to manage network-load-balancers in the relevant compartment.

Read More: [Policies For Network Load Balancers](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/policies/policies-for-network-load-balancers.html)

## Policies For Compartments

Compartment policies provide DR with read access to all resources in a specified compartment or across the tenancy. The access can be granted to a dynamic group for resource principals or to a user group through compartment- or tenancy-scoped statements.

Read More: [Policies For Compartments](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/policies/policies-for-compartments.html)

## Policies For Automatic DR Configuration

Resource principal authentication is a prerequisite for configuring Automatic Disaster Recovery.

Read More: [Policies For Automatic DR Configuration](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/policies/policies-for-automatic-dr-configuration.html)

## Policies For Integration Instance

Integration instance recovery requires the resource principal dynamic group or authenticated user group to manage integration-instance resources in the target compartment.

Read More: [Policies For Integration Instance](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/policies/policies-for-integration-instance.html)

## Policies For Generative AI

Generative AI integration requires the DR dynamic group or authenticated user group to use the generative-ai-family in the relevant compartment. Existing Full Stack DR dynamic groups do not require matching-rule changes; only the additional policy statement is needed.

Read More: [Policies For Generative AI](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/policies/policies-for-generative-ai.html)


# Troubleshooting

## Launching Dr Operations During A Home Region Outage

If the home IAM region is unavailable, OCI Console access to Full Stack DR may be interrupted, preventing DR Plan execution through the console. Initiate recovery using the REST API or another supported interface, such as the OCI CLI, Terraform, or Python; the CLI `dr-plan-execution create` command accepts an execution-options file specifying whether prechecks and warnings are enabled and whether to run a failover or failover precheck.

Read More: [Launching Dr Operations During A Home Region Outage](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/troubleshooting/launching-dr-operations-during-a-home-region-outage.html)

## Resetting Dr Configuration After A Failover

After a successful failover, manually clean up the former primary DR protection group and reverse member configurations before subsequent switchover or failover operations. Confirm the former primary is a standby with an Active state, then refresh and verify all DR plans. Tasks vary by resource: reverse replication for volume groups, file systems, and buckets; avoid terminating removed buckets; remove and terminate applicable compute resources and storage; reconfigure non-moving instance attachments and mounts; reinstate databases through Data Guard; update load balancer backend sets; and remove the `brie` namespace and DR-managed namespaces from OKE clusters along with their associated resources.

Read More: [Resetting Dr Configuration After A Failover](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/troubleshooting/resetting-dr-configuration-after-a-failover.html)

## Updating Backend Server Ip Addresses In Oci Load Balancer Backend Sets After Dr Operation

After a switchover, failover, or start drill, load balancers may fail to route traffic to newly launched backend resources in the new primary region. Check the health checks for every DR-managed load balancer, and if checks fail, update the backend server IP addresses in the affected backend sets.

Read More: [Updating Backend Server Ip Addresses In Oci Load Balancer Backend Sets After Dr Operation](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/troubleshooting/updating-backend-server-ip-addresses-in-oci-load-balancer-backend-sets-after-dr-operation.html)


# Reference

## Dependency Mapping

Dependency mapping enables Full Stack Disaster Recovery to identify relationships among OCI resources in primary and standby DR Protection Groups and generate recovery plans in prerequisite order. It automatically groups drill, failover, and switchover steps according to resource dependencies; this default sequence should not be changed without careful evaluation. The Reorder groups and steps feature allows administrators to customize group ordering and move individual steps between groups to reflect business-specific dependencies.

Read More: [Dependency Mapping](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/reference/dependency-mapping.html)

## Events

Full Stack Disaster Recovery emits OCI events for DR Protection Group, DR Plan, and DR Plan Execution operations. Events use begin and end notifications for actions such as creation, update, association, role changes, deletion, switchover, failover, drill execution, cancellation, pausing, resuming, retrying, and ignoring executions. Event payloads follow the CloudEvents format and generally identify the source service, event time, compartment, resource name, resource OCID, and availability domain.

Read More: [Events](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/reference/events.html)

## Lifecycle States Of Full Stack Disaster Recovery Resources

Full Stack Disaster Recovery resources use lifecycle states to indicate availability, progress, failure, and required intervention. DR Protection Groups can be Creating, Active, Updating, Needs attention, Deleting, Deleted, Failed, or Inactive, with a Drill in progress sub-state. DR Plans use Creating, Updating, Active, Inactive, Deleting, Deleted, Failed, or Needs attention states and may require refresh or verification after configuration changes. DR Plan Executions progress through Accepted, In progress, Pausing, Paused, Resuming, Succeeded, Failed, Canceling, Canceled, Deleting, or Deleted states, with restrictions on available actions in each state. Automatic DR Plan Configurations have comparable states and can report resource-principal or associated-plan problems through lifecycle sub-states.

Read More: [Lifecycle States Of Full Stack Disaster Recovery Resources](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/reference/lifecycle-states-of-full-stack-disaster-recovery-resources.html)

## Prechecks Performed By Full Stack Disaster Recovery

Full Stack Disaster Recovery validates the readiness of protected resources before recovery operations, including compute instances, file systems, mounts, volume groups, block-volume attachments, Object Storage, database services, Autonomous Database and Container Database, OKE, MySQL HeatWave, Integration instances, and PostgreSQL systems. Checks cover replication or backup availability, resource lifecycle states, region and availability-domain placement, encryption and vault configuration, network and security rules, database roles and connectivity, cluster mappings, node pools, mount prerequisites, and valid member relationships. Supported operations receive operation-specific checks for switchover, failover, start drill, or stop drill; PostgreSQL supports switchover and failover only.

Read More: [Prechecks Performed By Full Stack Disaster Recovery](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/reference/prechecks-performed-by-full-stack-disaster-recovery.html)

## How To Migrate From An Existing Compute Instance To A New Instance Type

Migrating a legacy Compute Instance to a Movable or Non-Movable Compute instance requires removing the existing member from the DR Protection Group and adding it again with the new instance type and properties. Because this is treated as a member deletion and addition, all existing DR Plans must be refreshed and verified, and custom steps or plan changes must be recreated. The migration can be performed through the Console or REST API and enables features such as capacity reservations, block-volume operations, and File Storage mount or unmount actions.

Read More: [How To Migrate From An Existing Compute Instance To A New Instance Type](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/reference/how-to-migrate-from-an-existing-compute-instance-to-a-new-instance-type.html)

## Migrating Using The Console

Console migration involves selecting the relevant legacy compute members in a DR Protection Group, recording their existing properties, removing them, and accepting the warning that plans require refresh and verification. The instances are then added again as Movable or Non-Movable Compute members with their required properties and configuration, and the process is repeated in both primary and standby groups. After migration, plans can be regenerated and user-defined steps restored; removing member properties also requires plan refresh.

Read More: [Migrating Using The Console](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/reference/migrating-using-the-console.html)

## Migrating Using The Rest Api

REST API migration begins by retrieving the DR Protection Group and its member definitions, removing legacy compute members through an update request, and adding replacement members with the appropriate COMPUTE\_INSTANCE\_MOVABLE or COMPUTE\_INSTANCE\_NON\_MOVABLE member types. Existing movable instances retain VNIC mappings, while the legacy `vnicMapping` property becomes `vnicMappings` in the new representation; non-movable instances do not use that mapping. The update payload must preserve other DR Protection Group members, such as volume groups.

Read More: [Migrating Using The Rest Api](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/reference/migrating-using-the-rest-api.html)

## Default Order Of Dr Plan Groups

Full Stack DR plans use operation-specific group sequences that establish dependencies for switchover, failover, start drill, and stop drill operations. These sequences coordinate prechecks, storage and database transitions, compute and network changes, File Storage and Object Storage operations, OKE processing, cleanup, and DR Protection Group membership changes. Administrators should restore the documented default order after manually reordering groups or when plan refreshes produce incorrect ordering, because executing plans with improperly ordered groups can cause failures or unpredictable recovery results.

Read More: [Default Order Of Dr Plan Groups](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/reference/default-order-of-dr-plan-groups.html)

## Dr Protection Group Configuration Changes Requiring Plan Refresh

DR Plans require refresh and verification after adding or removing DR Protection Group members, changing a compute member between Movable and Non-Movable types, or modifying relevant member properties. Changes include File Storage export mappings, Movable Compute destination capacity reservations, Non-Movable Compute start and stop behavior, and block-volume mappings. These updates can invalidate plan data, so plans must be refreshed and verified before execution.

Read More: [Dr Protection Group Configuration Changes Requiring Plan Refresh](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/reference/dr-protection-group-configuration-changes-requiring-plan-refresh.html)

## Full Stack Dr Billing Details

Full Stack DR billing is based on allocated OCPU, ECPU, or Oracle Integration message packs for supported compute, database, OKE, and Oracle Integration members in each DR protection group, regardless of whether resources are running or stopped. Moving compute is charged only in the primary region, while non-moving compute and database, OKE, and Oracle Integration resources are charged in both regions when present. Storage, networking, Oracle applications, and non-Oracle applications do not incur Full Stack DR charges. Resource consumption is obtained from OCI resource details, with Exadata database allocations approximated by dividing VM cluster CPU by the number of hosted databases and OKE consumption calculated from node-pool size multiplied by per-node OCPU. Cost estimates should reflect resources in their normal operating locations and can be prepared with the Full Stack DR or comprehensive OCI cost estimator; examples demonstrate charges for moving compute, replicated databases, non-moving compute, OKE, and Oracle Integration configurations.

Read More: [Full Stack Dr Billing Details](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/reference/full-stack-dr-billing-details.html)

## Full Stack Dr Built-In Plan Groups For Dr Plans

Full Stack DR supports compute, Oracle and open-source database systems, volume groups, file systems, Object Storage buckets, load balancers, OKE clusters, and Oracle Integration instances, with member placement determined by the resource’s primary, standby, moving, or non-moving topology. DR plans include switchover, failover, start drill, and stop drill, and automatically generate resource-specific built-in plan groups whose steps run in parallel within each group. Correct dependencies and regional membership are essential: moving compute and its boot and block volumes belong in the primary group, non-moving compute belongs in both groups as applicable, databases and replicated services are paired by role, and storage, networking, OKE, and Integration resources must be added according to their topology. Built-in workflows orchestrate actions such as launching, stopping, attaching, replicating, restoring, scaling, switching over, and cleaning up resources; support varies by resource and plan, with unsupported scenarios requiring user-defined plan groups or custom scripts.

Read More: [Full Stack Dr Built-In Plan Groups For Dr Plans](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/reference/full-stack-dr-built-in-plan-groups-for-dr-plans.html)

## Quickdr

QuickDR provides a guided way to create a dedicated Full Stack DR configuration for a compute instance or add the instance to an existing configuration from the OCI console. It provisions disaster recovery for dependent block storage and networking resources, but not file systems or other unsupported resources, which can be added later. For a new configuration, users specify the name, compartment, peer region, optional destination networking and VNIC mappings, fault-domain preference, destination compartment and placement, dedicated VM host or capacity reservation options, and tags. For an existing configuration, users select the target DR protection group and an existing volume group, or allow QuickDR to create one, then update the configuration. Default OCI-selected values can be overridden, and the workflow can be created or canceled at the final step.

Read More: [Quickdr](https://docs.oracle.com/en/cloud/iaas/disaster-recovery/cssgm/reference/quickdr.html)