What is the difference between RTO and RPO?

RTO (Recovery Time Objective) is how long you can be down before the impact is unacceptable — the target time to restore service. RPO (Recovery Point Objective) is how much data loss is tolerable, measured as the maximum age of the last good backup you can restore from.

How do I choose RTO and RPO values?

Work backward from business impact. A payment system might need an RTO of minutes and an RPO near zero, while an internal analytics dashboard might tolerate hours of downtime and a day of data loss. Tighter targets cost more, so match them to each system's real importance.

Why include a contact tree?

During a real disaster, people scramble to find who can authorize a failover or restore a backup. A documented contact tree with roles and escalation order removes that delay and ensures the right people are reached fast.

How often should a DR plan be tested?

At least annually, and quarterly for critical systems. An untested DR plan is a hypothesis, not a plan. Testing surfaces stale credentials, missing access, and broken backups before a real incident does.

Is my plan stored anywhere?

No. The builder runs fully in your browser and never sends your plan to a server, so it is safe to draft confidential recovery details here.

Disaster Recovery Plan Builder

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

Plan for the day a system fails

Every critical system will eventually fail, lose data, or become unreachable. A disaster recovery plan turns that inevitability into a known, rehearsed procedure with explicit recovery targets. This builder produces a structured DR plan covering scope, RPO and RTO objectives, a system inventory, recovery steps, a contact tree, and a testing cadence.

How it works

The builder organizes your inputs into the standard DR plan sections. Scope defines which systems and failure scenarios the plan addresses. The objectives capture the overall RTO and RPO. The critical system inventory is a table where each line you enter (system, RTO, RPO, owner) becomes a row, making per-system targets visible at a glance. The recovery procedure is rendered as ordered steps. The contact tree and testing schedule are bullet lists.

RTO is the maximum tolerable downtime; RPO is the maximum tolerable data loss. Setting both per system forces an honest conversation about what each system is worth, which is the real value of writing a DR plan.

Tips and example

Enter inventory rows as system, RTO, RPO, owner, for example Payments DB, 15 min, 1 min, Platform team.
Set RPO equal to your backup frequency or tighter. If you back up daily but claim a 1-hour RPO, the plan is fiction.
Write recovery steps assuming the primary region is gone. If a step depends on the failed system, it belongs elsewhere.
Schedule a real restore test, not just a tabletop exercise. Restoring from backup is the step most likely to fail in practice.