Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery (DR) orchestrates the transition of compute, databases, and applications between OCI regions from around the globe with a single click. Customers can automate the steps needed to recover one or more business systems without redesigning or re-architecting existing infrastructure, databases, or applications and without needing specialized management or conversion servers.
OCI Full Stack DR is available in OCI commercial regions, UK government regions, EU sovereign regions, Oracle Alloy regions, and OCI Dedicated Regions. For a comprehensive list of service availability, you can refer to the Full Stack DR regions availability page. The onboarding process for Oracle US Government Cloud and Oracle US Defense Cloud regions is still in process. For further information regarding OCI regions, including realms and their specific locations, check out the OCI realms and regions documentation.
OCI Full Stack Disaster Recovery currently caters to resources available within OCI regions, and resources must be in the same tenancy. Full Stack DR supports the Oracle Database@Azure offering, which means database-level role transitions can be handled only using Full Stack DR. However, it's important to note that the ability to support disaster recovery in on-premises, hybrid, and multicloud strategies is part of the roadmap for future development. Oracle plans to extend the functionality of OCI Full Stack DR to encompass these environments, allowing you to have a comprehensive disaster recovery solution that covers a broader range of scenarios.
No. Disaster recovery in OCI requires all OCI services to support cross-tenancy operations. Very few OCI services support cross-tenancy replication or control. Since Full Stack DR relies on the capabilities and APIs provided by all OCI services, Full Stack DR can’t provide recovery orchestration until all OCI services support cross-tenancy capabilities.
Yes, it can. Deploying OCI resources across two OCI regions provides enhanced disaster recovery capabilities. This approach helps ensure high availability and resiliency for critical applications and services. In the event of a disaster or outage in one region, resources can seamlessly fail over to the other region, reducing downtime and minimizing the impact on business operations. By distributing resources across multiple regions, you can achieve a robust disaster recovery strategy that offers improved data protection and business continuity.
No, OCI Full Stack DR is a fully managed service.
Yes, OCI Full Stack DR provides availability and performance SLAs. For more details, refer to the Oracle PaaS and IaaS Public Cloud Services Pillar Document (PDF).
You can access OCI Full Stack DR using the Oracle Cloud Infrastructure console (a browser-based interface), REST APIs, Oracle Cloud Infrastructure SDKs, a command-line interface, and DevOps tools.
Yes, OCI Full Stack DR can be used for both Oracle and non-Oracle workloads.
No. By design, Full Stack DR allows you to create DR plans only in the standby DR protection group region. It’s highly recommended that you use a test execution of a switchover plan to create all the DR plans (switchover, failover, and drill plans) in the other DR protection group. This will ensure that the DR plans are available in both regions.
It depends on the application requirements. If there are no application dependencies (for example, if multiple DB switchovers can happen in parallel with application server recovery), then having multiple DR protection groups would be ideal. This would also help improve the business application’s overall recovery time objective. However, if the recovery steps depend on each other, having a recovery plan in a single DR protection group would make sense. Full Stack DR is highly flexible; you can create DR protection groups and DR plans according to your requirements.
OCI Full Stack DR helps automate the recovery steps for existing applications. To integrate with Full Stack DR, you’ll need to complete the following:
Yes, Full Stack DR is a highly flexible service. You can integrate any DR DR deployments with OCI Full Stack Disaster Recovery.
You’ll need to set up all the production/DR infrastructure and application components. Depending on your DR deployments, this could include the following:
You can add the following resource types as members of the DR Protection group.
While creating the DR plan, OCI Full Stack Disaster Recovery automatically generates built-in plan groups. Your DR plan can be further customized to interact with any other OCI services through user-defined plan groups using scripts or Oracle Cloud Infrastructure Functions.
There are four types of DR plans.
Yes, we have plans to add other OCI core services, such as OCI Kubernetes Engine (OKE). Check back for more information.
Yes. OCI Full Stack DR depends on the Oracle Database PaaS Data Guard APIs for generating plan groups for switchover or failover for the database. But having said that, you can use custom scripts to control Oracle Data Guard role changes in cases where Data Guard was set up manually.
Yes, assuming you have Oracle Data Guard set up for the databases running in an OCI VM. You can create user-defined plan groups and use the Data Guard broker or role reversal scripts.
We recommend that you follow the native database replication technologies for replicating the production and standby databases. You can use user-defined plan groups and bring in your own scripts for performing the database role reversal.
Moving instance: Typically used in pilot light or cold VM disaster recovery topologies where instances that comprise the application stack are only deployed in the primary region. The instances are moved from the primary DR protection group to the standby DR protection group.
Non-moving instance: Typically used for active-passive DR topologies where instances that comprise the application stack are predeployed in both regions and application software components. You start or stop these instances during DR operations to transition the service from one region to another.
If you added a moving or non-moving compute instance as a member in the primary DR protection group, you must add the relevant boot/block volume group as a member in the primary DR protection group.
You can specify the block volume mount option details in the non-moving instance member properties. You must add the relevant block volume group as a member in the primary DR protection group.
No, you can’t add these DBs as member types with Full Stack DR. Once the native cross-region replication features are released from the respective service, the Full Stack DR team will plan to have support for these services as member types. Today, customers can use custom scripts and integrate those with Full Stack DR if the recovery process for the DBs can be completed. For example, HeatWave MySQL supports cross-region backup and restore features; if the recovery process can be scripted, those can be added to the DR plan using the user-defined plan groups.
Recovery time objective (RTO): The RTO is the targeted time frame within which a particular application or system must be fully restored and operational after a disaster or disruptive event. It represents the maximum allowable downtime the business can tolerate for that application. In other words, it indicates how quickly the application needs to be up and running again to meet business continuity requirements. Critical applications often have a low RTO, as they need to be restored quickly to minimize disruptions and maintain essential operations.
Recovery point objective (RPO): The RPO refers to the maximum tolerable data loss in case of a disaster or disruption. It represents the period of time for which data may be lost (not backed up or replicated) before the disaster starts to significantly impact the business. For instance, if an application has an RPO of one hour, it means that after a disaster, the data must be recovered to a point no more than one hour before the incident occurred. Applications with a lower RPO typically require more frequent data backups or replication to ensure minimal data loss.
Both the RTO and RPO are essential considerations in disaster recovery planning as they directly impact the continuity and resilience of business operations during and after a disruptive event. Organizations need to balance these objectives based on the criticality of their applications and the cost of implementing the necessary DR measures.
The RTO for an application can be determined by considering the time it takes to complete the switchover or failover plan. OCI Full Stack DR, with its fully automated recovery process, can significantly improve the RTO by minimizing downtime and reducing the manual intervention required for recovery.
By automating the failover and switchover processes, OCI Full Stack DR streamlines the recovery workflow and enables applications to be brought back online quickly. This reduction in recovery time can lead to improved business continuity and reduced disruptions during a disaster.
OCI Full Stack DR doesn’t have control of the RPO, as it can vary based on the OCI services, their replication methods, and configurations. Different services within Oracle Cloud Infrastructure may have specific RPO guidelines depending on how they handle data replication and synchronization.
For example, for Oracle Autonomous Database Serverless, Oracle may have published RPO values for cross-region standby databases indicating the maximum tolerable data loss for that specific setup.
To ensure compliance with your desired RPO and to understand the data recovery capabilities of each OCI service, refer to the respective OCI service’s documentation. These guidelines provide detailed information on how data is replicated, what recovery options are available, and the expected RPO for different configurations. By following the recommendations in the documentation, you can implement an appropriate disaster recovery strategy that aligns with your business needs and data protection requirements.
The pricing for OCI Full Stack DR follows the OCI OCPU and ECPU per-hour pricing model. The service is priced based on the CPU (OCPU and ECPU) count of each member type added to a DR protection group. It only uses the allocated CPUs to calculate charges. Storage, networking, and other resource usages that are part of Full Stack DR protection groups are not billed by Full Stack DR.
For more details, refer to the OCI cost estimator and OCI pricing list (PDF).
OCI Full Stack DR is priced based on the number of OCPUs and ECPUs of compute and database resources added as members in both the primary and standby DR protection groups.
Example 1
Example 2
Please note that the pricing per hour and model can change in the future. For current pricing, refer to the latest pricing guidelines or contact your Oracle sales representative.
No, there’s no separate pricing for adding a volume group as a member in a DR protection group. The OCI Full Stack DR pricing only applies to compute and database member types. Full Stack DR doesn’t charge extra for the following OCI resource types:
Yes. You’ll pay the normal costs of the OCI services needed to deploy the application stack whether you’re using Full Stack DR or not. You’ll pay for OCI Networking, OCI Compute, OCI storage consumption, OCI Load Balancer, Oracle databases, and any other OCI services your application stack requires. The cost of Full Stack DR is an additional cost based on the number of ECPUs and OCPUs as explained in answer to question 2 of this section.
The cost associated with OCI services and a DR deployment model will vary depending on the specific services and configurations you choose. For instance, if you opt for cross-region block replication, there will be an additional storage cost. Similarly, using an autonomous standby database will also incur additional expenses. For more detailed information on pricing for each respective OCI service, please refer to the Oracle Cloud Infrastructure pricing details.