Design, inspect, validate, and operate OCI Full Stack Disaster Recovery orchestration. Use for DR protection groups, members, associations, DR plans, plan groups and user-defined steps, prechecks, drills, planned switchovers, unplanned failovers, reprotection, readiness evidence, RTO/RPO validation, and cross-region or intra-region application recovery. Database Data Guard remains with oci-database-cloud; storage replication remains with oci-storage.
Installation
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Design, inspect, validate, and operate OCI Full Stack Disaster Recovery orchestration. Use for DR protection groups, members, associations, DR plans, plan groups and user-defined steps, prechecks, drills, planned switchovers, unplanned failovers, reprotection, readiness evidence, RTO/RPO validation, and cross-region or intra-region application recovery. Database Data Guard remains with oci-database-cloud; storage replication remains with oci-storage.
OCI Disaster Recovery
Operate Full Stack Disaster Recovery as an orchestration owner, not as a
substitute for provisioning protected resources. A protection group is ready
only when dependencies, plans, prechecks, recovery evidence, and owners agree.
Routing
Intent
Owner
Full Stack DR protection groups, associations, plans, prechecks, drills, transitions
This skill
Volume, file-system, or bucket replication and backup
oci-storage
Base Database/Exadata Data Guard
oci-database-cloud
ADB backup/restore and lifecycle
oci-autonomous-db
Project or landing-zone architecture requirements
oci-project / oci-landing-zone
HCL and state ownership
oci-terraform-authoring
Workflow
Capture service criticality, scope, RTO/RPO, data-loss tolerance, primary/standby roles, owners, and authority.
Read both locations and the complete dependency graph: protected resources, replication, network/DNS, IAM, secrets, and application sequencing.
Read protection groups, association health, plan definitions, work requests, last precheck, last drill, and current role.
Compare the DR plan to the reviewed dependency order and explicit rollback/reprotection checkpoints.
Run readiness/precheck work before any drill or transition. Treat accepted asynchronous work as incomplete until terminal state and postchecks.
Classify drills conservatively and all traffic/data-role transitions as destructive; require exact context-bound preview and approval.
Verify application, data, network, DNS, observability, and ownership state in the recovery location, then record actual RTO/RPO.
Common multi-step flows
Request
Sequence
Assess readiness
requirements → dependency inventory → protection/replication state → plan review → precheck → gap report
Never infer readiness from an ACTIVE protection group alone.
Never expose OCIDs, addresses, DNS answers, secret references, or application topology.
A precheck is evidence, not approval for a later transition.
Drill, switchover, and failover plans can disrupt service or change data authority; treat execution as destructive.
Never run a failover merely because a health signal is absent or inconsistent. Confirm scope, permissions, time window, region, and source telemetry.
Keep Terraform ownership for protected resources; DR orchestration does not silently take ownership.
Verification and rollback
Verification must cover terminal work-request state, application health, data
integrity/freshness, network and DNS routing, observability, primary/standby
roles, and measured RTO/RPO. Rollback is the reviewed reverse transition when
safe, or incident recovery followed by reprotection and a new precheck. Never
promise automatic failback or zero data loss.
