3.1 Full Stack Disaster Recovery: Protection Groups, Members & Permissions

What Full Stack DR Does

Disaster recovery projects rarely fail because replication breaks. They fail because the runbook that coordinates databases, storage, compute, and traffic is manual, out of date, or never tested. OCI Full Stack Disaster Recovery (Full Stack DR) is a managed orchestration service that turns that runbook into repeatable DR plans. It does not replace native replication. Instead, it drives services you have already configured, such as Data Guard, Autonomous Data Guard, block volume group replication, File Storage replication, and Object Storage replication, and it coordinates them with compute launches and load balancer updates.

Oracle defines disaster recovery as restoring a business system after an outage, either in the same geographic region or in another region. Most exam scenarios use two regions, such as Ashburn and Phoenix.

Key Terms

Member Types

When you create DR plans, Full Stack DR inspects the members of both DRPGs and generates built-in plan groups for them. Supported member types include:

Moving vs. Non-Moving Compute

• A moving instance exists only in the primary region during normal operation. It is the classic pilot light or cold VM topology. You add the instance and the volume group that contains its boot and block volumes to the primary DRPG only. During a switchover or failover, Full Stack DR recovers the volume group in the standby region and launches the instance there, applying the VNIC mappings you defined (destination subnet, and optionally the same private IP and hostname if the destination subnet allows them).
• A non-moving instance is pre-deployed in both regions (a warm standby). Each region's instance is added to its own DRPG. Full Stack DR starts and stops them, and it can also detach replicated block volumes from the primary instance and attach them to the standby instance.

Databases, Storage, and Load Balancers

• For Oracle Database services, the primary database goes in the primary DRPG and the standby database in the standby DRPG. Data Guard (or Autonomous Data Guard) must already be configured, and the database password is supplied through a Vault secret.
• For File Storage and Object Storage, you add the primary file system or bucket to the primary DRPG and configure replication beforehand.
• For load balancers, Full Stack DR does not create or provision anything. Load balancers must already exist in both regions. Full Stack DR updates their backend sets so traffic reaches the instances that are active after the transition.

Role Reversal

After a successful switchover, the DRPG that was standby becomes primary, and the old primary becomes standby. Plans are then created or refreshed in the new standby group so you can switch back later. Oracle provides a DR plan refresh option to keep existing plans when members are added, removed, or changed, instead of deleting and recreating them.

Permissions: Users and the DRPG Resource Principal

Two kinds of permissions matter.

1. Permissions for people. Full Stack DR resources use the disaster-recovery-family, which contains disaster-recovery-protection-groups, disaster-recovery-plans, disaster-recovery-plan-prechecks, disaster-recovery-plan-executions, and disaster-recovery-workrequests. For example, Oracle's sample policies let one group fully administer DR, and another group create protection groups, plans, and prechecks without being able to execute plans:

Allow group DRUberAdmins to manage disaster-recovery-family in tenancy
Allow group DRConfig to manage disaster-recovery-protection-groups in compartment ApplicationERP
Allow group DRConfig to manage disaster-recovery-plans in compartment ApplicationERP

2. Permissions for the service to act on members. Oracle recommends resource principal authentication. You create a dynamic group whose matching rule includes the DR protection groups, plus the compute instances (needed for running commands on them), and grant that dynamic group access to the member services:

All {resource.type='drprotectiongroup', resource.compartment.id='<drpg_compartment_ocid>'}
Allow dynamic-group fsdr-dg to manage instance-family in compartment AppCompute
Allow dynamic-group fsdr-dg to manage volume-family in compartment AppStorage
Allow dynamic-group fsdr-dg to manage database-family in compartment AppDB
Allow dynamic-group fsdr-dg to read secret-family in compartment Vaults

If these permissions are missing, prechecks and plan executions fail when Full Stack DR tries to act on the member resources.

Getting Started Quickly: QuickDR

For a single compute instance, QuickDR sets up a DR configuration from the instance itself. It can create a new, dedicated Full Stack DR configuration for the instance (protection groups, volume group, and plans) or add the instance to an existing configuration. It is a fast path for pilot light protection of individual VMs.