Pilot-light DR for a 120-VM booking engine over a 1 Gbps FastConnect

Connectivity. Terminate the FastConnect on a DRG attached to the hub VCN, with private peering or a virtual circuit to the on-premises DRG. Confirm CIDRs are non-overlapping across data center and both regions before anything else - overlap discovered late forces a re-IP of the DR build. Keep a site-to-site VPN as a backup path in case the FastConnect circuit is cut, since the same incident may hit both sites.

Replication, chosen per tier rather than uniformly.

• Databases (12 Oracle instances): Data Guard in async or fast-sync mode to the OCI region. Async keeps the primary isolated from WAN latency while staying well inside a 15-minute RPO. This is the only tier where a warm standby is worth the steady-state cost, because it is the hardest to rebuild.
• Non-database VMs: block volume replication (asynchronous, cross-region) for boot and data volumes, plus periodic object storage copies for file shares. This is the pilot-light mechanism - storage is replicated and billed, compute is not running.
• Compute: keep no running fleet. Store custom images and instance configurations so the 120 VMs are recreated on demand from the same definitions, and keep Terraform for the VCN, load balancers and policies.

Why this fits. Steady state is storage, one DRG, and the database standbys - nothing like 120 running instances. The 15-minute RPO is met by the database and block-volume replication lag; the 4-hour RTO is achievable because compute is recreated from definitions rather than designed.

Do not replicate with rsync over FastConnect as the primary mechanism - at 1 Gbps shared with production traffic, a full re-sync after a change window will blow the RPO and saturate the circuit.

The arithmetic of a 4-hour RTO. Decompose it: detection (minutes), decision (minutes to tens of minutes), database switchover (minutes), compute creation and boot (~10-20 minutes for 120 VMs at realistic concurrency limits), application smoke test, and DNS/endpoint switching. That last one silently eats the budget if the TTL is long - a 3600-second TTL is an hour you did not plan for.

What must be true before the drill.

• Capacity in the DR region actually available for the shapes you need (service limits raised in advance, not on the day).
• Images, instance configurations and Terraform state present and current in the DR region.
• IAM policies, dynamic groups, vault secrets and wallet files resolvable in the DR region.
• Load balancers and backend sets pre-created and empty, so failover is a target update rather than a build.
• DNS with health checks and a short TTL, or an equivalent traffic-management steering policy that can be flipped.

Run the test as a switchover, not an outage. Use OCI Full Stack Disaster Recovery (or a documented runbook) to orchestrate; perform a planned database switchover, launch the compute fleet from definitions, flip DNS, and time each step from decision to first successful booking transaction. Record the wall-clock number, not an estimate.

Common misses that turn 4 hours into 4 days: an untested FastConnect failure path, GPUs or specialised shapes unavailable in the DR region, licenses or OS activation tied to the primary site, and a booking tier that depends on a middleware component nobody included in the 120-VM inventory. Test the failure of the dependency, not just the database.

Repeat quarterly and shrink the number each time; a DR plan that has only been reviewed is a hypothesis, and the exam judgement is to budget for the endpoint switch as seriously as for the data.