Disaster Recovery (DRaaS)

How are RPO and RTO set for a DRaaS disaster recovery site?

Designing a disaster recovery service (DRaaS) starts with two targets. RPO (recovery point objective) shows how much data, looking back, is acceptable to lose in an outage. RTO (recovery time objective) defines how quickly a system must be back in service at the disaster recovery site. These values are set by the business before any technology is chosen; applying the same target to every application leads either to unnecessary cost or to inadequate protection.

At MAV Cloud, RPO and RTO values are defined per project, based on each system’s criticality tier. A typical classification looks like this:

• Critical systems: ERP, production and sales applications; continuous replication and priority failover order.
• Important systems: file servers, internal applications; replication at set intervals.
• Supporting systems: test environments, archives; restoring from backup may be sufficient.

How to document targets and scenarios is explained step by step in our how to create a disaster recovery plan guide.

Service assurance: A request raised during a disaster is handled as critical priority; the service level agreement sets a 15-minute first-response target for this priority. From the failover decision to informing business units, the process aligns with MAV Cloud’s ISO 22301 certified business continuity and ISO/IEC 27001 certified information security management systems (see our certifications).

MAV Cloud’s CDP (continuous data protection) based disaster recovery platform targets an RPO of 15–60 seconds and an RTO of 5–15 minutes for critical systems. These are targets, not commitments; they are set per project based on the system design and are planned to be validated with a failover test. Organizations receiving the disaster recovery service include Sardis Portföy Yönetimi, an asset management company.

Failover and failback testing

A disaster recovery plan that has never been tested may not deliver the expected result in a real outage. Testing follows these steps:

1. Scope and order: which virtual machines are started and in what order, along with dependencies (for example Active Directory first, then the database, and the application server last), is defined.
2. Isolated test: replicas are started in an environment separated from the production network; production keeps running.
3. Validation: the application is confirmed to start, and data consistency and user access are checked; the measured time is compared with the RTO target.
4. Failback rehearsal: for the return to the primary site, only the data changed during the outage is planned to be transferred back.
5. Reporting: deviations, missing steps and runbook items that need updating are recorded.

How often to test depends on how quickly the infrastructure changes. Rolling out a new application, changing the network design or adding virtual machines means the plan must be tested again. The runbook should also spell out how DNS records, external access addresses and VPN connections will be redirected during failover; a system that is technically up does not count as in service if users cannot reach it. Decision-making authority is also clarified in advance: who makes the failover call, which channel is used for communication and how business units are kept informed are all added to the plan. In the ISO 22301 business continuity approach, these roles and communication steps are considered as important as the technical steps.

Comparing disaster recovery site approaches

Restoring from backup alone is a reasonable option for supporting systems; for critical systems, however, restore time grows with data volume and target hardware must be ready at that moment. A second in-house data center delivers speed, but it keeps generating hardware, licensing and maintenance costs even when idle. With DRaaS, the secondary site’s resources are consumed as a service; replication, monitoring and testing are part of the provider’s operations.

DRaaS is built on data replication. First-response targets during an incident are defined on our SLA page.

To estimate the hourly and per-incident cost of an outage, use the downtime cost calculator; the result gives a baseline for recovery targets and budget decisions.