Demanding zero data loss and instant recovery for every system blows the budget. A practical way to classify systems through business impact analysis and pick the right RPO/RTO target and technology for each.
Ask many SMBs about their disaster recovery (DR) plan and the answer is "we back up every night." But a backup is a copy of data; disaster recovery is getting the business running again. If you don't know in advance how much data you can lose and how long you can be down after a fire, hardware failure or ransomware attack, you don't have a plan. These two questions are answered by RPO and RTO.
What Are RPO and RTO?
- RPO (Recovery Point Objective): the maximum acceptable amount of data loss, measured in time. If you back up every night, your RPO is about 24 hours; a disaster in the afternoon loses all of that day's data.
- RTO (Recovery Time Objective): the maximum acceptable time until the system is usable again.
The shorter both are, the higher the cost. So instead of aiming for "zero loss, instant recovery" everywhere, systems should be grouped by their importance to the business.
Step 1: Business Impact Analysis
Ask these questions for each system:
- What do we lose if this system is down for an hour? Sales, production, customer satisfaction, contractual penalties?
- If the last hour of data in this system is lost, can we recreate it?
- Is there a legal or contractual availability obligation?
- Which other systems does it depend on?
IT should not do this analysis alone, but together with the business units. The team that uses a system knows best whether it is critical.
Step 2: Group Systems into Tiers
- Tier 1 — Critical: ERP, e-commerce, payment and order systems. Target: RPO in minutes, RTO in a few hours. Suitable technology: continuous replication to a different data centre.
- Tier 2 — Important: email, file server, CRM. Target: RPO 1–4 hours, RTO the same business day. Suitable technology: frequent replication or snapshot copies.
- Tier 3 — Supporting: archive, test and development environments. Target: RPO 24 hours, RTO a few days. Suitable technology: restore from off-site backup.
Step 3: Map Dependencies and Order
Bringing an application server up in minutes is useless if authentication (Active Directory) and DNS are down. Write down the recovery order: network, identity and DNS first; then databases; applications and user access last. The plan should also cover how IP addresses, DNS records and VPN connections change in the DR environment.
Step 4: A Runbook for the Disaster
- Who declares a disaster, and based on which criteria?
- Which system is brought up by whom, and in what order?
- What is communicated to employees, customers and suppliers, and through which channel?
- How and when do you fail back to the primary data centre?
Step 5: Drills
An untested DR plan is just an assumption. Run drills at least twice a year and measure the actual RTO. Modern replication solutions let you run drills in a separate test network without affecting production. Update the plan after every drill.
Don't Forget the Ransomware Scenario
Replication copies encrypted data to the DR side within seconds too. Your DR solution must therefore keep not only the "latest state" but also historical recovery points. Plan the retention of the replication journal together with your immutable backups so you can return to a clean point just before the attack began.
Common Mistakes
- Mistaking backups for a disaster recovery plan
- Keeping the DR copy in the same building or data centre as production
- Skipping the network, DNS and user access plan
- Writing the plan and never testing it
- No clear plan owner or review frequency
CloudRUX DRaaS
CloudRUX DRaaS uses Zerto-based continuous replication to copy your virtual servers to a separate data centre in Turkey and lets you run drills without affecting production. Within the scope of our ISO 22301 business continuity management certification, we can tier your systems and set the right RPO/RTO target for each together. Contact us at info@cloudrux.com for an assessment.