Disaster Recovery Plan: Set RTO and RPO First

Most businesses have backups. Far fewer have a disaster recovery plan that says how quickly systems must come back, how much data the business can afford to lose and exactly who does what when a serious failure happens. Without those answers, recovery becomes improvisation under pressure: people search for credentials, guess at the order of steps and discover that backups are incomplete or slower to restore than expected. A disaster recovery plan turns recovery into a rehearsed process. The starting point is agreeing two objectives with the business, recovery time and recovery point, and then choosing technical options that meet them at a sensible cost. This guide explains how to set those objectives, pick a recovery approach and test the plan.

What a disaster recovery plan covers

A disaster recovery plan describes how to restore important systems and data after a serious disruption, such as a cloud region outage, ransomware, accidental deletion, a failed migration or the loss of a key supplier. It typically includes:

• Which systems are covered and how important each is
• Recovery objectives for each system
• The technical approach used to recover
• Step-by-step recovery procedures
• Roles, contacts and decision-making authority
• Communication plans for staff, customers and suppliers
• A testing schedule and record of results

AWS guidance notes that a disaster recovery plan should be a subset of an organisation's business continuity plan rather than a standalone document (AWS: Business continuity plan and recovery objectives). Technology recovery is one part of keeping the business running.

Set RTO and RPO first

Two objectives drive every technical decision. AWS defines them as follows:

• Recovery Time Objective (RTO): the maximum acceptable delay between the interruption of service and restoration of service
• Recovery Point Objective (RPO): the maximum acceptable amount of time since the last data recovery point, which determines how much data loss is acceptable

These are business decisions, not technical ones. Ask system owners: if this system stopped, how long could the business cope? If we restored it, how much recent data could we afford to re-enter or lose? Answers often differ widely between systems.

Classify systems by importance

Group systems into tiers so effort goes where it matters:

• Critical: systems that stop revenue or core operations, such as order processing or customer portals
• Important: systems the business can work around for a while, such as internal reporting
• Deferrable: systems that can wait days, such as archives or some internal tools

Each tier gets its own RTO and RPO. Not every system needs the fastest, most expensive recovery.

Map dependencies

Systems rarely recover alone. An order application may depend on a database, an identity service, a payment provider, DNS and a message queue. Map these dependencies and recover them in the right order. A system with a short RTO cannot meet it if one of its dependencies takes much longer to restore.

Choose a recovery approach

AWS guidance groups disaster recovery strategies into four broad approaches, ranging from the low cost and low complexity of making backups to more complex strategies using multiple active regions (AWS: Disaster recovery options in the cloud):

• Backup and restore: keep backups and rebuild systems from them when needed
• Pilot light: keep core data replicated and minimal infrastructure ready, scaling up during recovery
• Warm standby: run a scaled-down but working copy of the environment that can take over
• Multi-site active/active: run the workload in several locations at once

Match the approach to each system's RTO and RPO. Backup and restore suits many deferrable and important systems; critical systems may justify pilot light or warm standby.

Worked example: objectives and approaches by system

The table below is a hypothetical recovery plan summary for a mid-sized business. The objectives are illustrative and would need agreement with system owners.

SystemTierRTORPOApproachBackup locationCustomer order portalCritical4 hours15 minutesWarm standby in second regionReplicated database, second regionCRM integration serviceImportant1 day1 hourPilot lightReplicated data, infrastructure as codeInternal reportingImportant2 days24 hoursBackup and restoreDaily backups, second regionDocument archiveDeferrable1 week24 hoursBackup and restoreObject storage, second region

Protect backups

Backups are only useful if they survive the disaster. Keep copies in a separate location, such as another region or account, so a single failure or compromised account cannot destroy both production and backups. Restrict who can delete backups, and consider immutable storage options where your provider offers them. Encrypt backups and manage the keys carefully, because losing the keys can make backups unusable.

For SaaS systems such as CRMs, check what the provider backs up and what remains your responsibility. Our guide to Zoho CRM data backup covers backing up CRM data you rely on.

Write clear recovery procedures

For each system, write the steps to recover it: where backups are, how to restore them, how to rebuild infrastructure, how to reconnect dependencies and how to confirm the system works. Store procedures somewhere available during an outage, not only on the systems that might fail. Keep credentials for recovery accessible to authorised people through a secure process.

Define roles and decisions

Decide in advance:

• Who can declare a disaster and start recovery
• Who leads the technical recovery
• Who communicates with staff, customers and suppliers
• How decisions are escalated if the plan does not fit the situation

Include contact details and backups for each role, since key people may be unavailable.

Test the plan regularly

An untested plan is an assumption. Test at different levels:

• Restore tests: restore a backup to a separate environment and check data
• Walkthroughs: talk through the plan step by step with the people involved
• Partial failovers: recover one system in the secondary environment
• Full exercises: simulate a major outage and recover critical systems

Measure actual recovery times and data loss against RTO and RPO, record gaps and fix them.

Consider multi-region where justified

For critical systems with demanding objectives, running in more than one region may be part of the answer. Our guide to multi-region architecture explains the trade-offs involved.

Keep the plan current

Update the plan when systems, suppliers, staff or business priorities change. Review it at least once a year and after every test or real incident.

Frequently Asked Questions

What is a disaster recovery plan?

It is a documented process for restoring important systems and data after a serious disruption, including objectives, technical approaches, procedures, roles and testing.

What are RTO and RPO?

RTO is the maximum acceptable delay between interruption and restoration of service; RPO is the maximum acceptable time since the last data recovery point.

Which disaster recovery approach should a business choose?

The one that meets each system's RTO and RPO at sensible cost, ranging from backup and restore to pilot light, warm standby or active/active.

How often should a disaster recovery plan be tested?

Regularly, with restore tests and walkthroughs at least yearly, and fuller exercises for critical systems, plus updates after every test or incident.

Be ready before disaster strikes

We help businesses set recovery objectives, design backup and standby options and run recovery tests. See our custom app development services, or talk to us about your disaster recovery plan.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.