OCI Full Stack Disaster recovery

OCI Full Stack Disaster Recovery does not dictate the Recovery Point Objective (RPO) since it can vary depending on the OCI services, their replication methods, and configurations. Various services in Oracle Cloud Infrastructure may adhere to specific RPO guidelines based on their approach to data replication and synchronization.

The Recovery Time Objective (RTO) for an application is gauged by the duration needed to execute the switchover or failover plan. OCI Full Stack Disaster Recovery, with its comprehensive automated recovery process, can markedly enhance the RTO by minimizing downtime and diminishing the need for manual intervention in the recovery process.

Through the automation of failover and switchover procedures, OCI Full Stack Disaster Recovery simplifies the recovery workflow, facilitating the swift restoration of applications. This decreased recovery time contributes to enhanced business continuity and decreased disruptions in the event of a disaster.

OCI Full Stack Disaster Recovery from Oracle Cloud Infrastructure (OCI) streamlines the relocation of compute, database, and applications across global OCI regions with a simple click. This solution empowers customers to automate the recovery process for one or multiple business systems without the necessity for a redesign or re architecture of their existing infrastructure, databases, or applications. Moreover, specialized management or conversion servers are not required for this seamless orchestration.

OCI Full Stack Disaster Recovery facilitates the automation of recovery steps for current applications. To integrate with Full Stack DR, you will need to accomplish the following:

• Document outlining the disaster recovery procedures or instructions for restoring your business system.
• Application deployment process.
• Tailored scripts based on the specific requirements of the application

You are required to establish the entire production/DR infrastructure and application components based on your specific DR deployments. This includes:

• Networking resources, such as Oracle Cloud Infrastructure (OCI) VCN and Load Balancer.
• A standby database system or database, depending on the type of Oracle Database PaaS; internally, Oracle Data Guard is employed for Oracle Database replication.
• Storage replication, which varies according to the type of Oracle Cloud Infrastructure (OCI) Storage services utilized for boot/block setup and volume group replication.

At present, OCI Full Stack Disaster Recovery is designed for resources within OCI regions. It's worth highlighting that the roadmap for future development includes expanding disaster recovery capabilities to encompass on-premises, hybrid, and multi-cloud strategies. Oracle aims to enhance OCI Full Stack DR functionality, providing a comprehensive disaster recovery solution that addresses a wider range of scenarios.

No, OCI Full Stack DR is a fully managed service.

Yes, OCI Full Stack Disaster Recovery is compatible for both Oracle and non-Oracle workloads.

You have the option to include the subsequent resource types as members within the DR Protection group.

• Oracle Cloud Infrastructure (OCI) Compute virtual machines (VM and destination-dedicated VM)
• Oracle Database PaaS
  • Autonomous Database
  • Oracle Base Database
  • Oracle Exadata on Dedicated Infrastructure
• Volume group (For boot and block volumes)

OCI Full Stack Disaster Recovery relies on the Oracle Database PaaS Data Guard APIs to create plan groups for database switchover or failover. You need to setup Oracle Data Guard for the databases running in an OCI VM. You can create user-defined plan groups and use Data Guard broker or role reversal scripts.

Moving instance: Commonly employed in pilot light or cold VM disaster recovery configurations, where instances forming the application stack are exclusively deployed in the primary region. These instances are transferred from the primary DR protection group to the standby DR protection group

Non-moving instance: Generally applied in active-passive DR topologies, where instances constituting the application stack and application software components are pre-deployed in both regions. During DR operations, you initiate or halt these instances to transition the service from one region to another