Full Stack Disaster Recovery Terminology and Concepts

Before using Full Stack DR, familiarize yourself with the following key terms and concepts.

• Disaster Recovery (DR) – The process of restoring some or all parts of a business system (a service) after an outage. The recovery of this business system can occur in the same geographical region or in another geographical region.
• Full Stack – A term used to collectively refer to all the functional layers of a business system or application or software service. An application can be comprised of different functional layers or tiers such as: application layer, middleware layer, database layer, and infrastructure layer.
• Recovery Point Objective (RPO) – The RPO defines the maximum amount of data loss that can be tolerated as part of the DR restoration. RPO is typically expressed in units of time.
• Recovery Time Objective (RTO) – The RTO defines the maximum amount of time that the application or service under DR protection can be unavailable until service is restored. RTO is typically expressed in units of time.
• Primary – The production version of an application or service that is currently in use. Full Stack DR refers to the Primary version of an application as having a Primary role.
• Standby – The reserved version of an application or service. Standby is also used to refer to the alternate region in which the application or service will be restored. Full Stack DR refers to the Standby version of an application as having a Standby role.
• Warm Standby - A DR model in which some or all of the components of an application or service are pre-deployed in the standby region to prepare for a future DR transition. This model involves higher operating costs but a lower RTO.
• Cold Standby - A DR model in which very few or none of the components of an application or service need to be pre-deployed in the standby region in preparation for a future DR transition. The application components are deployed as part of the DR transition. This model involves lower operating costs but a higher RTO.
• Role – Specifies whether an application and its region is currently the Primary (production) version or the Standby (reserved) version. An application's and its region's role changes as a result of a DR transition.
• Resource – A resource is a component in OCI that can be used and managed independently. Examples of OCI resources are: compute instances, block volumes, databases, load balancers, etc. Examples of resources provided by Full Stack DR are: DR Protection Groups, DR Plans, and DR Plan Executions.
• DR Protection Group – A resource type used by Full Stack DR. A DR Protection Group represents a consistency grouping defined for the purposes of disaster recovery. It is a collection of different OCI resources that comprise an application and must be treated as a combined group when performing disaster recovery operations. For example, a DR Protection Group may consist of application servers (compute instances), associated block storage (grouped as volume groups), and databases.
• Association – A pair relationship defined between two DR Protection Groups. DR Protection Groups in Full Stack DR must be associated (paired) in a Primary and Standby relationship before they can be used to implement DR services. An association between two DR Protection Groups is exclusive, that is, a DR Protection Group can only be associated with one other DR Protection Group.
• DR Plan – A resource type used by Full Stack DR. A DR Plan represents a DR workflow associated with a pair of DR Protection Groups. A DR Plan is represented as a sequence of Plan Groups. These Plan Groups in turn consist of Plan Steps. A DR Plan can only be created at the Standby DR Protection Group.
• DR Plan Execution – A resource type used by Full Stack DR. A DR Plan Execution represents an execution (a running instance) of a DR Plan. A DR Plan Execution can only be created (launched) at a Standby DR Protection Group.
• Plan Group – A group of steps in a DR Plan. A DR Plan consists of one or more Plan Groups that execute sequentially. All steps in a Plan Group execute in parallel.
• Plan Step – A single indivisible unit of execution in a DR Plan. A Plan Step must belong to a Plan Group.
• Built-In Groups or Steps – A type of Plan Group or Step that is generated automatically by Full Stack DR when a DR Plan is created. Examples of Built-in Plan Steps are: Launch Compute Instance, Switchover Database, etc.
• User-Defined Groups or Steps– A type of Plan Group or Step that is added by the user to a DR Plan after the DR plan is created by Full Stack DR.
• Precheck – A predetermined set of checks associated with a DR Plan. A Precheck for a DR Plan performs a set of checks to validate that a DR Plan is compliant with the members and configuration of the DR Protection Groups with which the DR Plan is associated. Prechecks are used to perform ongoing DR Plan validation (DR readiness checks) to ensure that the DR Plan (DR workflow) stays aligned with the topology it protects.
• Switchover – A type of DR Plan that performs a planned transition of services from the Primary DR Protection Group to the Standby DR Protection Group. Switchover plans perform an orderly transition by shutting down the application stack in the primary region and then bringing it up in the standby region. Therefore, a switchover plan requires that application stack components and other required OCI services be available in both regions.
• Failover – A type of DR Plan that performs an unplanned transition of services to the Standby DR Protection Group. Failover plans usually perform an immediate transition by bringing up the application stack in the standby region, without attempting to shutdown service in the primary region. Hence, a failover plan only requires that OCI services be available in the standby region. Failover plans are typically used to perform DR transitions when an outage or disaster affects the primary region.
• DR Drill - Performing a DR Drill for a pair of associated DR Protection Groups brings up a replica of the application stack in the standby DR Protection Group. This replica stack can be used to test and validate the effectiveness of the DR processes. A Start DR Drill plan execution creates the application stack replica in the standby, and a Stop DR Drill plan execution terminates this application stack replica.