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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.