Disaster recovery planning: RTO and RPO

Disaster Recovery; Not an Option, but a Necessity

Imagine it's 3 AM and a human error in the main database has deleted today's order table. Or a ransomware attack has encrypted all your server files. At that moment, the only thing that matters is this: how long will it take for the system to come back, and how much data have you lost? The answer to these two questions is exactly what is known in the technology world as RTO and RPO, and they form the foundation of any disaster recovery plan.

Many organizations think having a weekly backup is enough, but when a real crisis occurs, they realize that not defining these two metrics means losing complete control over the recovery process. In this article, in simple but technical language, you will learn what RTO and RPO are, how to calculate them, and how to build a real and practical disaster recovery plan based on them.

What are RTO and RPO? A Precise Definition of Two Critical Concepts

These two terms look similar at first glance, but they refer to two completely different aspects of recovery. Confusing them can lead to designing a plan that doesn't work in practice.

RTO (Recovery Time Objective); Time Until Return

RTO is the maximum amount of time your organization can survive without its critical systems. This number is calculated from the moment a disaster is declared until the moment the service returns to normal. If your RTO is 4 hours, it means you must be able to bring servers, network, and applications back up within 4 hours.

For example, an online store that sells 50 million Tomans per hour would lose 400 million Tomans in revenue if it's down for 8 hours. Therefore, the RTO for this business should clearly be less than 8 hours.

RPO (Recovery Point Objective); Maximum Acceptable Data Loss

RPO refers to the furthest point in time from which you can recover data. In other words, it's the maximum amount of data loss that is acceptable to you in the event of a disaster. If your RPO is 24 hours, it means in the worst-case scenario, you lose one day's worth of data.

Suppose you have a news website that publishes several articles every hour. If your RPO is 6 hours, you might lose 6 hours of published news, which for a media outlet means losing credibility and audience.

How to Determine RTO and RPO for Your Business?

Determining these numbers is not purely a technical decision; it's a business decision. To calculate correctly, you need to follow these three steps.

Step One: Identify Critical Systems

Not all systems have the same importance. An online payment database is vastly different from an internal newsletter email system. For each system, conduct a Business Impact Analysis (BIA) and categorize them into three groups:

• Critical: Their downtime means a complete halt of the business (e.g., payment gateway, main database)
• Important: Their downtime causes serious disruption, but the business doesn't completely stop (e.g., content management system)
• Non-critical: Their downtime has minimal impact and can wait for days (e.g., internal reporting system)

Step Two: Calculate the Cost of Downtime and the Cost of Data Loss

For each critical system, calculate two numbers:

1. Cost per hour of downtime: The sum of lost revenue, salaries of idle employees, contractual penalties, and brand reputation costs
2. Cost per unit of lost data: The cost of data reconstruction, lost opportunities, and legal risks

Then, set RTO based on the budget you have for recovery infrastructure and RPO based on what you can afford to lose. As a general rule, smaller RTO and RPO mean higher infrastructure costs.

Step Three: Documentation and Agreement

Record the resulting numbers in a formal document and get approval from senior management. This document will be the basis for infrastructure design and the selection of backup tools. Without this agreement, any change in infrastructure might unintentionally violate the RTO or RPO.

Designing a Disaster Recovery Plan Based on RTO and RPO

Now that you have the numbers, it's time to design the technical architecture. The choice of solution directly depends on your RTO and RPO values.

Backup and Recovery Strategies

There are four main strategies, each offering a different combination of RTO and RPO:

• Traditional Backup: Suitable for RPO of several hours and RTO of several hours. Data is periodically copied (e.g., every 6 hours) to a separate storage space. Recovery requires installing the operating system, restoring data, and testing.
• Pilot Light: Suitable for RPO of about 15 minutes and RTO of about 1 hour. A minimal version of the infrastructure (e.g., a small database) is always running in a second region, and data is continuously replicated. During a disaster, you bring up the main services.
• Warm Standby: Suitable for RPO of about 5 minutes and RTO of about 15 minutes. A full copy of the infrastructure is on standby, but traffic is not directed to it. You just need to change the DNS.
• Active-Active (Multi-Site): Suitable for RPO close to zero and RTO close to zero. Two sites are active simultaneously, and traffic is load-balanced between them. If one fails, the other continues on its own.

Practical Example: Designing for an Online Store

Suppose you have an online store with 1000 daily orders. Your analysis shows:

• Cost per hour of downtime: 20 million Tomans
• Maximum acceptable data loss: 30 minutes (i.e., RPO = 30 minutes)
• Maximum allowable downtime: 2 hours (i.e., RTO = 2 hours)

Based on these numbers, the Warm Standby strategy is a suitable choice. To implement it, you need to:

1. Set up a second server in another data center (or a different cloud region).
2. Keep the database synchronized using continuous replication (such as MySQL Replication or PostgreSQL Streaming Replication).
3. Synchronize static files (product images) with tools like rsync every 5 minutes.
4. Have a failover script ready that automatically changes the IP or DNS to the second server.

A simple example of a failover script for changing DNS using an API could look like this:

#!/bin/bash
# Simple failover script - change DNS record
# This is a conceptual example, not production-ready

PRIMARY_IP="192.168.1.10"
SECONDARY_IP="192.168.2.10"
DOMAIN="shop.example.com"

# Check if primary is reachable
if ! ping -c 3 -W 2 $PRIMARY_IP > /dev/null 2>&1; then
    echo "Primary is down. Switching DNS to secondary..."
    # Call DNS provider API to update A record
    curl -X POST "https://api.dnsprovider.com/v1/update" \
        -H "Authorization: Bearer YOUR_API_KEY" \
        -d "domain=$DOMAIN&ip=$SECONDARY_IP"
    echo "Failover completed at $(date)"
fi

Common Mistakes in Disaster Recovery Plans

Many organizations fail during a crisis despite having a plan. The most common mistakes include:

Mistake One: Not Testing the Plan

A disaster recovery plan that has never been tested is a useless document. Conduct a full drill at least every 6 months. Do this in an isolated environment to avoid damaging production data. During the test, measure the actual recovery time and compare it with the defined RTO.

Mistake Two: Ignoring Dependencies

Recovering the database without recovering the application server is useless. Identify dependencies between services and specify the recovery order in the plan. For example, first the database, then the API, and finally the frontend.

Mistake Three: Forgetting Data Outside the Database

Many plans focus only on the database and forget user-uploaded files, logs, and configuration files. Include these files in your RPO and incorporate them into your backup strategy.

Implementation Tools and Techniques

There are various tools for implementing a disaster recovery plan. The choice of tools depends on your budget, team expertise, and current infrastructure.

Open-Source and Free Tools

• Bacula or Amanda: For traditional backup with advanced scheduling capabilities
• Rsync: For file synchronization between two servers
• MySQL Replication / PostgreSQL Streaming Replication: For continuous database replication
• Keepalived: For virtual IP management and automatic failover

Commercial and Cloud Tools

If you use cloud infrastructure, many providers offer integrated disaster recovery management tools. For example, ServerNet's cloud services allow you to define snapshots and replication between different regions, which can serve as a foundation for implementing Pilot Light or Warm Standby strategies. When choosing a service, be sure to pay attention to the provider's technical documentation and SLA.

Summary and Next Steps

A disaster recovery plan without specific numbers is a slogan, not a plan. By precisely defining RTO and RPO, you can design infrastructure that behaves exactly as you expect during a crisis. Remember:

• Determine RTO and RPO based on business impact analysis, not guesswork
• Choose the technical strategy based on these numbers, not personal preference
• Regularly test and update the plan

Start today: prepare a list of your critical systems, write an estimated RTO and RPO for each, and then schedule a meeting with your technical team. This is the first step toward building a real and executable disaster recovery plan.