**6.6 Advanced replication solution: continuous data protection (CDP)**

Mission-critical applications running on computer systems often require instant and unlimited data recovery points. Traditional data protection technologies offer a limited number of recovery points. If data loss occurs, the system can be rolled back only to the last available recovery point. Mirroring offers continuous replication; however, if logical corruption occurs to the production data, the error might propagate to the mirror, which makes the replica unusable. Ideally, CDP provides the ability to restore data to any previous point-in-time images (PIT). It enables this capability by tracking all the changes to the production devices and maintaining consistent point-in-time images. CDP enables one to perform operational recovery (protection against human errors, data corruption, and virus attacks) through local replication and disaster recovery through remote replication. CDP minimizes both RPO and RTO. In CDP, data changes are continuously captured and stored in a separate location from the primary storage. With CDP, recovery from data corruption poses no problem because it allows going back to any PIT image prior to the data corruption incident.

#### **6.7 Replication use case: disaster recovery-as-a-service (DRaaS)**

Facing an increased reliance on IT and the ever-present threat of natural or manmade disasters, organizations need to rely on business continuity processes to mitigate the impact of service disruptions. Traditional disaster recovery methods often require buying and maintaining a complete set of IT resources at secondary data centers that matches the business-critical systems at the primary data center. This includes sufficient storage to house a complete copy of all of the enterprise's business data by regularly replicating production data on the mirror systems at secondary site. This may be a complex process and expensive solution for a significant number of organizations.

Disaster Recovery-as-a-Service (DRaaS) has emerged as a solution to strengthen the portfolio of a cloud service provider, while offering a viable DR solution to consumer organizations. The cloud service provider assumes the responsibility for providing resources to enable organizations to continue running their IT services in the event of a disaster. From a consumer's perspective, having a DR site in the cloud reduces the need for data center space and IT infrastructure, which leads to significant cost reductions, and eliminates the need for upfront capital expenditure. Resources at the service provider can be dedicated to the consumer or they can be shared. The service provider should design, implement, and document a DRaaS solution specific to the customer's infrastructure. They must conduct an initial recovery test with the consumer to validate complete understanding of the requirements and documentation of the correct, expected recovery procedures.

For enterprises, the main goal of DR is business continuity, which implies the ability to resume services after a disruption. The Recovery Time Objective (RTO) and Recovery Point Objective (RPO) are two important parameters that all recovery mechanisms to improve. RTO is the time duration between disruption until the service is restored, and RPO denotes the maximum amount of tolerable data loss

*Network Function Virtualization over Cloud-Cloud Computing as Business Continuity Solution DOI: http://dx.doi.org/10.5772/intechopen.97369*

that can be afforded after a disaster. By minimizing RTO and RPO, business continuity can be achieved.

Failover delays consist of five steps depending on the level of backup [13]:

S1: Hardware setup S2: OS initiation time S3: Application initiation time S4: Data/process state restoration time S5: IP forwarding time

Therefore, RPO and RTO can be defined as: The Recovery Time Objective (RTO) The Recovery Point Objective (RPO)

$$PRO \propto \frac{1}{Fb} \tag{2}$$

Where Fb is Frequency of backup

$$\text{RTO} = \text{fraction of } \text{PRO} + \sum\_{S1}^{S5} T\_j \tag{3}$$

During normal production operations as shown in **Figure 14**, IT services run at the consumer's production data center. Replication of data occurs from the consumer production environment to the service provider's location over the network. Typically when replication occurs, the data is encrypted and compressed at the production environment to improve the security of data and reduce the network bandwidth requirements. Typically during normal operating conditions, a DRaaS implementation may only need a small share of resources to synchronize the application data and VM configurations from the consumer's site to the cloud. The full set of resources required to run the application in the cloud is consumed only if a disaster occurs.

In the event of a business disruption or disaster as shown in **Figure 15**, the business operations will failover to the provider's infrastructure as shown in the figure on the slide. In such a case, users at the consumer organization are redirected to the cloud.

For applications or groups of applications that require restart in a specific order, a sequence is worked out during the initial cloud setup for the consumer and recorded in the disaster recovery plan. Typically VMs are allocated from a pool of compute resources located in the provider's location.

Returning business operations back to the consumer's production environment is referred to as failback. This requires replicating the updated data from the cloud repository back to in-house production systems before resuming the normal

**Figure 14.** *DRaaS – Normal Production Operation.*

**Figure 15.** *DRaaS – Business Disruption.*

business operations at consumer's location. After starting the business operations at the consumer's infrastructure, replication to the cloud is re-established. To offer DRaaS, the service provider should have all the necessary resources and technologies to meet the required service level.

Cloud-based DR solutions are attractive because of their ability to tolerate disasters and to achieve reliability and availability goals. Such solutions can be even more useful in small and medium enterprises (SMEs) environments, because the latter does not have many resources (unlike large companies). As shown in **Table 2**, data level, system level, and application level are three DR levels, which are defined in terms of system requirements [14].

The performance requirements that have to be met by DR are to minimize RPO and RTO. There are different DR approaches to develop a recovery plan. All these approaches are based on redundancy and backup strategies if resources are systematically reserved in the backup. The redundancy strategy relies upon distinct sites that have the ability to start up the applications after a disaster; whereas backup strategy relies upon replication technology [15]. The speed and protection degree of these approaches depend on the level of DR services that is shown in **Table 3** [16].

The objective of disaster recovery planning is to minimize RTO, RPO, cost, and application latency by considering system constraints such as CPU, network, and



*DR levels.*


**Table 3.** *Cloud-based DR models.* *Network Function Virtualization over Cloud-Cloud Computing as Business Continuity Solution DOI: http://dx.doi.org/10.5772/intechopen.97369*

storage requirements. DR recovery planning can be considered as an optimization problem. DR plans include at least two phases:

