In this second post we will discuss how the RTO and RPO are important and how Hyper-V Replica fits these concepts.

Recovery Time Objective and Recovery Point Objective

Basically the terms indicate the RTO and RPO objectives that a disaster solution must comply with:

RTO – maximum time to replace the service in production

RPO — maximum data that can be "lost" between the disaster event and the restored environment

A good example of how these values relate to each other and what they mean can be explained in the chart below:

In the above example we can "see" clearly the RTO and RPO:

RTO was 5 hours and 3 minutes, between the 05:15 and the 10:18

RPO was 3 hous and 15 minutes, between the 02:00 and the 05:15, since the backup was performed the 2 a.m.

How to determine the RTO and RPO

These values are determined by a plane which is called the DRP (Disaster Recovery Plan) which is orchestrated by consultancies specialized in this type of process. It is usually done when an organization is upgrading its datacenter and reviewing their data recovery policies or redundant datacenter mounting.

The process of survey data is based on interviews and data from the it environment and, among other things, collects:

Because Hyper-V Replica is a great option

The backup process is one of the ways that the RPO and RTO can be met, but the normal restore practices often preclude taking into account the time that is lost between the last backup and the failure (RPO) and the time required to restore a server from backups (RTO).

With Hyper-V replicates the RTO time is minimal, since the replicas keep the virtual machine (VM) in redundancy environment integrates.

And the RPO?

In a backup environment the RPO is easily calculated and maintained. For example, if the RPO of the CRM application has maximum loss calculated in 30 minutes, can make incremental backup every 15 or 30 minutes.

In the case of Hyper-V Replicates this time is not determined in a simple way, since the time of replication (Replication) of each VM indicates the range and not the desired period of protection. It would be nice to have an option where you could be indicated what the maximum time that a replica can be outdated.

A second important item is to take into account the Group of an application, for example more than one server that forms the same application and needs to be with the synchronized replica. How Hyper-V Replica does not have the concept of service group, we have no way to ensure the integrity of the entire application.

Another difficulty in Hyper-V Replica is the low number of replica range options (Windows 2012 every 5 minutes, Windows 2012 R2 every 30 seconds, 5 minutes or 15 minutes):

Imagine a cluster with 80 VMs, each VM has different impact on business or technical requirements. Of these 80 some VMs are web servers that can be replicated once a day, others are application servers that only need to be replicated when you suffer some sort of update and finally we have the servers that need to be replicated continuously.

How to configure different RPO?

A practice that can be adopted in a simple way, is to put the machines in criticity groups and configure using the 3 Windows Windows 2012 R2 replica (30 seconds, 5 minutes and 15 minutes).

The problem is that if the VM that is replicated every 30 seconds, for example a database and the environment for WAN redundancy, link consumption will be too high and the other VMs will be in range of replica and all replicas will occur simultaneously. With that, the RPO will be impaired for all VMs criticism and very low for the machines don’t criticize.

A good practice in this case is to configure VMs with RPO greater than 2:0 to be replicated manually through PowerShell below:

This command can be executed by the Task Scheduler or using the Orchestrator with schedule embedding the command.

In the example above, the VMs or database information such as File Server would be with the configuration of the Hyper-V itself every 5 or 15 minutes. The static VMs could be configured with replication and manual tasks or scheduled and recurring runbook replicate promptly as the Group of criticality.

Conclusion

This second post discussed how to achieve the RTO and RPO.

The next post will address the commands and the sequence of PowerShell commands that can be run as a script or with Runbook in Orchestrator.