What are RTO and RPO?

Summary

• RTO (Recovery Time Objective) is the maximum acceptable time to restore service after an outage. RPO (Recovery Point Objective) is the maximum acceptable amount of data loss, measured as the time since the last recovery point.
• Lower RTO and RPO mean less downtime and less data loss, and they guide how you design high availability and disaster recovery on the Databricks Platform.
• For high availability within a cloud region, the Databricks control plane fails over automatically to healthy availability zones, typically within a 15-minute RTO and with an RPO of 0 (no committed data lost).
• For disaster recovery across regions, you set RTO and RPO targets per workload and choose an active-passive, active-active, or backup-and-restore pattern. Databricks documents example tiers such as critical (RTO under 1 hour, RPO under 15 minutes), important (RTO under 4 hours, RPO under 1 hour), and standard (RTO under 24 hours, RPO under 24 hours).
• Databricks Managed Disaster Recovery targets roughly a 15-minute RPO and RTO, replicating Unity Catalog metadata, managed table data, and workspace assets to a secondary region behind a stable URL that survives failover.

What are RTO and RPO?

RTO (Recovery Time Objective) and RPO (Recovery Point Objective) are the two numbers that define how resilient a system must be. RTO is the maximum time a business can tolerate being down before service is restored. RPO is the maximum amount of data, expressed as a window of time, that the business can afford to lose. Lower values mean less downtime and less data loss, but they require more investment and operational rigor. On the Databricks Platform, RTO and RPO drive two complementary designs: high availability (HA) for failures inside a cloud region, and disaster recovery (DR) for the loss of an entire region.

Why the Databricks Platform helps you meet RTO and RPO

• Automatic high availability inside a region. The Databricks control plane is deployed across multiple availability zones and fails over automatically to healthy zones if one zone is affected, typically within a 15-minute RTO and with an RPO of 0 so no committed data is lost. This applies to regions with multiple availability zones; the control plane is resilient because its services are stateless and workspace data is stored in databases replicated across zones. See Design a high availability strategy.
• Serverless and classic compute resilience. Serverless compute provides automatic multi-zone failover with no additional configuration. Classic compute distributes cluster nodes across availability zones when workspace subnets span multiple zones, so a single-zone failure does not take a workload down.
• Disaster recovery across regions, sized to your targets. DR addresses a full regional outage and is measured by the RTO and RPO you choose, typically in the range of hours. Databricks documents three design patterns you can match to your targets: active-passive (a standby secondary region with periodic replication), active-active (both regions serving traffic with continuous replication for a lower RTO), and backup and restore (the lowest cost, with the highest RTO and RPO). See Design a disaster recovery strategy.
• Documented example RTO and RPO tiers. Databricks provides example targets you can adopt: critical workloads (RTO under 1 hour, RPO under 15 minutes), important workloads (RTO under 4 hours, RPO under 1 hour), and standard workloads (RTO under 24 hours, RPO under 24 hours).
• Managed Disaster Recovery. Databricks offers a managed disaster recovery capability that targets roughly a 15-minute RPO and RTO. It provides cross-region replication of Unity Catalog metadata, managed table data, and workspace assets, plus a stable URL that survives failover so clients reconnect without manual DNS changes. Read how it is used in production in How Databricks Managed Disaster Recovery helps Capital One achieve lakehouse resilience.
• Data replication built for recovery. For raw data, Databricks recommends geo-redundant cloud storage replication; for Delta tables, Delta Deep Clone replicates data across regions. Streaming workloads synchronize checkpoints across regions so they can resume after failover.

Getting started

• Start with Understand your business needs and set an RTO and RPO for each workload based on how much downtime and data loss it can tolerate.
• Choose serverless compute for automatic multi-zone resilience, or deploy classic compute subnets across at least two availability zones.
• Select a DR pattern (active-passive, active-active, or backup and restore) that meets each workload's RTO and RPO, and replicate Delta tables across regions with Delta Deep Clone.
• Consider Databricks Managed Disaster Recovery for an end-to-end, cross-region option that targets a roughly 15-minute RPO and RTO.
• Test your recovery procedures regularly so your measured RTO and RPO match your targets.

FAQs

What is the difference between RTO and RPO?

RTO measures time to recover (how long service can be down); RPO measures data loss (how much recent data, in time, can be lost). A four-hour RTO means service must be back within four hours; a 15-minute RPO means no more than 15 minutes of data may be lost.

What RTO and RPO does Databricks provide for a zone failure?

For a single availability zone failure inside a multi-zone region, the Databricks control plane fails over automatically, typically within a 15-minute RTO and with an RPO of 0, meaning no committed data is lost.

How do I meet RTO and RPO across an entire region?

Choose a cross-region disaster recovery pattern (active-passive, active-active, or backup and restore) sized to your targets, replicate data with geo-redundant storage and Delta Deep Clone, and optionally use Databricks Managed Disaster Recovery, which targets a roughly 15-minute RPO and RTO.