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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.