What RTO, RPO do you offer?

Summary

• Databricks does not impose a single fixed RTO or RPO. Recovery Time Objective (RTO) and Recovery Point Objective (RPO) are targets you define based on your business needs, and you achieve them through a disaster recovery architecture on the platform.
• RTO is how long your business can tolerate downtime; RPO is how much data loss is acceptable. Both are set per workload according to how critical it is.
• Databricks documentation gives example targets by workload tier: critical workloads RTO < 1 hour and RPO < 15 minutes; important workloads RTO < 4 hours and RPO < 1 hour; standard workloads RTO < 24 hours and RPO < 24 hours.
• You choose a DR design pattern to match your targets: active-passive, active-active, or backup-and-restore, trading cost and complexity against faster recovery and lower data loss.
• The platform provides the building blocks to hit your targets: Delta Deep Clone and geo-redundant replication for data, Terraform and CI/CD for code and workspace objects, Unity Catalog metadata replication, SCIM identity federation, streaming checkpoint sync, and failover workspace URLs.

What RTO, RPO do you offer?

Databricks does not publish a single fixed RTO or RPO that applies to every deployment. Recovery Time Objective (RTO, the acceptable downtime) and Recovery Point Objective (RPO, the acceptable data loss) are objectives that each organization defines for its own workloads, then meets by designing a disaster recovery (DR) architecture on the platform. Disaster recovery is the ability to recover from an outage affecting an entire cloud region and continue operations in a secondary region, and it is measured by acceptable downtime (RTO) and data loss (RPO). The right targets depend on how critical each workload is and on the cost and complexity you are willing to take on, because lower RTO and RPO targets increase both.

How Databricks helps you meet your RTO and RPO targets

Databricks Platform provides a structured approach and the building blocks to define and achieve your recovery objectives.

• Define targets by workload criticality. The disaster recovery strategy guidance gives example targets you can adopt: critical workloads at RTO < 1 hour and RPO < 15 minutes (active-active or active-passive with continuous replication); important workloads at RTO < 4 hours and RPO < 1 hour (active-passive with hourly replication); and standard workloads at RTO < 24 hours and RPO < 24 hours (backup and restore).
• Choose a DR design pattern. Active-passive keeps a secondary region on standby with periodic replication and manual or automated failover. Active-active serves traffic from both regions with continuous replication for better RTO at higher cost. Backup and restore is the lowest-cost option with the highest RTO and RPO, suitable for non-critical workloads.
• Replicate data across regions. Use Delta Deep Clone to replicate Delta tables across regions, geo-redundant replication for external and managed data and landing zones, and checkpoint synchronization or dual writes for streaming endpoints.
• Reproduce code and workspace objects. Deploy platform infrastructure with infrastructure-as-code and Terraform, keep notebooks and code in version control, and deploy to both regions with CI/CD so the secondary site stays in sync.
• Keep identities and governance consistent. Use SCIM synchronization at the account level and identity federation for consistent access across regions, and replicate Unity Catalog metadata, table definitions, and access controls to the secondary region.
• Fail over cleanly. Point clients at failover workspace URLs and update DNS or load balancer configuration so traffic moves to the secondary region during an outage.

Getting started

• Start with Disaster recovery: Understand your business needs to identify critical services and set target RPO and RTO for each.
• Use the disaster recovery strategy guide to choose a design pattern and plan DR across clients, code, identities, Unity Catalog, data, and streaming.
• Test failover and failback regularly so your measured recovery matches your target RTO and RPO.

FAQs

Does Databricks guarantee a specific RTO or RPO?

No. RTO and RPO are targets you define for your own workloads based on business needs, and you meet them through the DR architecture and replication cadence you choose on the platform.

What RTO and RPO should I aim for?

It depends on workload criticality. Databricks documentation offers example targets: critical workloads RTO < 1 hour and RPO < 15 minutes, important workloads RTO < 4 hours and RPO < 1 hour, and standard workloads RTO < 24 hours and RPO < 24 hours.

What determines how low my RTO and RPO can be?

Your DR design pattern and replication frequency. Continuous replication with active-active or active-passive designs supports the lowest RTO and RPO, while backup and restore is lower cost but recovers more slowly with more potential data loss.