Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery (DR) orchestrates the transition of compute, database, 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 rearchitecting existing infrastructure, databases, or applications—and without needing specialized management or conversion servers.
At present, OCI Full Stack DR is available in 27 regions within the OC1 commercial realm. For a comprehensive list of these regions, you can refer to the Full Stack DR regions availability page. Our upcoming plan involves promptly expanding its availability to the remaining OC1 regions, followed by OCI Dedicated Regions and other OCI regions. For further information regarding OCI regions, including realms and their specific locations, check the a href="https://docs.oracle.com/en-us/iaas/Content/General/Concepts/regions.htm" data-lbl="oci-realms-regions">OCI realms and regions documentation.
Currently, OCI Full Stack Disaster Recovery caters to resources that are available within OCI regions. However, it's important to note that the capability for 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.
Yes, it is possible. Deploying OCI resources across two OCI regions provides enhanced disaster recovery capabilities. This approach helps to ensure high availability and resiliency for critical applications and services. In the event of a disaster or outage in one region, resources can fail over to the other region seamlessly, 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. Full Stack DR allows you to create DR plans only in the standby DR protection group region.
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 deployments with OCI Full Stack Disaster Recovery.
You will need to set up all the production/DR infrastructure and application components depending on your DR deployments.
You can add the following resource types as members in 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 (OCI) Functions.
There are four types of DR plans.
Yes, we have plans to add other OCI core services, such as OCI Container Engine for Kubernetes (OKE) and OCI Object Storage, as members. 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.
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 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 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.
Yes, by using user-defined plan groups. Please refer to Automate Switchover and Failover for OCI Object Storage Buckets Using Functions with OCI Full Stack Disaster Recovery.
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 that 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 the 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 event.
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, it is essential to refer to the respective OCI services 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 standard Oracle Compute Unit (OCPU) per hour pricing model. The stock keeping unit (SKU) for OCI Full Stack DR is B95485. For more details, refer to the OCI cost estimator
OCI Full Stack DR is priced based on the total number of OCPUs of compute and database resources that are added as members in both the primary and standby DR protection group.
Please note, pricing per hour and model can change in the future. Refer to the latest pricing guidelines or contact your Oracle sales representative for current pricing.
No, there is no separate pricing for adding a volume group as a member in a DR protection group. The pricing for OCI Full Stack DR is only applicable to compute and database member types.
Yes. 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.