TiDB Cloud Cross-Region PiTR: Disaster Recovery Without a Second Production Stack

Key Takeaways

• Cross-Region PiTR delivers region-level DR from backup data, not a duplicate live cluster or second production footprint required.
• RPO is minute-level: Mean 75s or less, P99 at 90s, P9999 at 120s. RTO is hour-level and tunable via restore cluster sizing and backup frequency.
• Recovery points are verified: Data and metadata must reach the secondary region before a timestamp is exposed as restorable.
• Available on AWS only; treat RPO/RTO figures as design targets and benchmarks, not contractual SLAs.

For mission-critical TiDB Cloud 전용 customers, high availability cannot stop at the region boundary. Single-region HA protects against node failures, availability-zone incidents, and localized infrastructure problems. When an entire cloud region becomes unavailable, customers need a verified recovery point in another region, a predictable restore path, and a cost model that does not require running a second full production stack at all times.

TiDB Cloud Cross-Region PiTR addresses this scenario. It continuously replicates full backups and log backups to a secondary region, validates restorable timestamps, and restores a new cluster on demand during a disaster or DR drill. The result is practical cross-region disaster recovery (DR) for production-scale TiDB workloads. This includes minute-level RPO targets, tunable hour-level RTO, verified recovery points, and steady-state cost driven primarily by object storage and cross-region replication.

Why Cross-Region Disaster Recovery Matters for TiDB Cloud Dedicated Customers

TiDB Cloud Dedicated runs large, business-critical workloads: SaaS platforms, gaming systems, fintech applications, trading systems, multi-tenant services, and high-write online workloads. These systems cannot treat a regional cloud outage as a purely theoretical event.

When a region-level disaster happens, the business needs clear answers:

• What is the latest point in time we can recover to?
• How much data might be lost?
• How long will it take before applications can reconnect?
• Can we prove that the recovery point is valid?
• Can we maintain this capability without paying for a full duplicate production environment every month?

Cross-Region PiTR addresses these questions by turning backup data into an operational recovery path. Instead of only storing a passive copy of backup files, TiDB Cloud continuously validates which recovery points are actually available in the secondary region and exposes them as restorable timestamps.

This expands the availability boundary of TiDB Cloud Dedicated from in-region HA to region-level disaster recovery.

How Cross-Region PiTR Works

Cross-Region PiTR combines four capabilities into one DR workflow.

1. Continuous backup production. TiDB Cloud continuously produces full backups and log backups in the primary region. Full backups provide the baseline snapshot. Log backups capture ongoing changes after the snapshot.
2. Cross-region replication. Backup data replicates to a secondary region through AWS S3 Cross-Region Replication. When Replication Time Control (RTC) is enabled, the replication path has a clearer time-bound behavior.
3. Recovery-point validation. TiDB Cloud validates the recovery point in the secondary region. The system does not simply mirror the upstream checkpoint. It verifies that the metadata and data files required for a timestamp have reached the secondary region before exposing that timestamp as recoverable.
4. On-demand restore. When disaster recovery is needed, TiDB Cloud creates a new cluster in the target region and restores it from replicated backup data. The restore process uses BR full restore, PITR restore, and compacted SST restore to bring the database back to a connectable state.

For customers, the experience is simple: maintain cross-region recovery readiness in a steady state, then restore to a verified point in time when a regional disaster or DR drill occurs.

How Continuous BR Innovation Makes This Possible

Cross-Region PiTR is possible because TiDB Backup & Restore (BR) has evolved from a backup utility into a large-scale recovery engine. Five capabilities carry the weight.

• BR full restore provides the physical recovery foundation. Full backups are stored as SST files, and multiple TiKV nodes can restore different data shards in parallel. This matters for hundred-terabyte-scale Dedicated clusters, where logical replay alone would not provide predictable restore time.
• BR PITR restore provides continuous recovery beyond the last full backup. With log backup, TiDB captures changes after the snapshot so customers can recover to a more recent timestamp rather than only to the last scheduled backup.
• Compacted SST restore improves the cost of incremental recovery. Instead of replaying a long window of fragmented log records through the full write path, TiDB compacts log backup data into restore-friendly SST files. This reduces the amount of logical replay and helps make hour-level recovery practical for large clusters.
• Restore phase splitting improves recovery efficiency. In a cross-region restore, snapshot restore runs while log backup compaction runs in parallel. After both complete, BR continues with PITR restore. This changes part of the recovery workflow from serial execution to parallel execution.
• Elastic TiKV scaling makes restore throughput tunable. Operators can provision a recovery cluster with more TiKV nodes during restore to increase parallelism, then scale it in after recovery. This makes RTO an engineering variable that teams can estimate and optimize, not a black-box outcome.

What RPO Does Cross-Region PiTR Target?

In Cross-Region PiTR, RPO is the time gap between the primary region failure and the latest restorable timestamp available in the secondary region. The current design targets minute-level recovery points.

Metric	Target
Mean RPO	≤ 75 s
P99 RPO	≤ 90 s
P9999 RPO	≤ 120 s

The end-to-end pipeline enables these targets: Frequent log backup flushing, cross-region object replication, recovery-point validation, and continuous monitoring.

In internal testing, downstream RPO stayed within the 60 to 90 second range, with occasional spikes caused by infrastructure or replication lag. This is why the right customer framing matters. Cross-Region PiTR provides a minute-level RPO design target under steady-state operation, while actual RPO during a regional incident depends on the health of the primary region, object storage, and replication pipeline before the outage becomes complete.

What RTO Can Customers Expect, and How Can They Tune It?

In Cross-Region PiTR, RTO covers the span from restore initiation to the point where applications can connect to the restored database. The key advantage is transparency. Teams can estimate restore time from data size, log volume, TiKV node count, instance type, storage throughput, and backup strategy:

Estimated RTO ≈ Snapshot Size / Snapshot Restore Rate
              + Log Volume / Log Replay Rate

In large-cluster testing, SST recovery speed is effectively capped by maximum disk bandwidth:

Disk Type	AWS Instance	Disk Throughput
io2	m8g.8xlarge (32c, 128 GB)	1.25 GiB/s
io2	m8g.16xlarge (64c, 256 GB)	2.5 GiB/s

For a hundred-terabyte-scale SaaS reference environment with 95 TiKV nodes, io2 storage, and a full snapshot of about 110 TB, reference RTO ranged from about 4.5 hours to a little over 6 hours depending on daily log volume, backup frequency, and TiKV instance size.

This is an important product advantage. Teams do not just observe recovery time after the fact. They can shape it through operational choices, including restore cluster size, TiKV instance class, storage throughput, and full backup frequency.

What Does Cross-Region Disaster Recovery Readiness Cost?

The business value of Cross-Region PiTR is not only that it provides region-level recovery. It provides this capability with a low steady-state cost profile.

Customers do not need to continuously run a full second production cluster just to be prepared for a regional disaster. In steady state, the cost is driven mainly by:

• Backup storage in the primary region.
• Replicated backup storage in the secondary region.
• Cross-region data transfer.
• Replication Time Control fees, when enabled.

A simplified pricing model:

Bill = Upstream backup storage
     + Downstream backup storage
     + Cross-region replication traffic
     + RTC traffic fee

During a DR drill or a real disaster recovery event, the customer also pays for short-lived recovery resources such as the target cluster, BR restore resources, and compaction workers. Those are event-time costs, not the normal monthly cost of maintaining readiness.

For large TiDB Cloud Dedicated deployments, this difference is significant. Region-level DR becomes closer to maintaining a verified remote recovery asset than to permanently operating another full production environment.

Built for Real DR Operations, Not Only Happy-Path Restores

Cross-Region PiTR is designed for real disaster recovery operations, not only for happy-path backup restoration.

The system exposes recoverable time and cross-region replica lag so operators can understand DR readiness. It supports internal alerting for replication lag, daemon health, S3 replication failure, and restore status. It also lays the foundation for auditability by recording RPO and RTO evidence. This can later be correlated with cloud provider incident timelines.

This matters because public cloud status pages do not always reflect the actual beginning of a regional incident. In a real DR event, customers need their own evidence of when replication stopped, what recovery point was available, and when restore was initiated. Cross-Region PiTR gives customers a stronger operational basis for making that decision.

Which Workloads Are the Best Fit for Cross-Region PiTR?

Cross-Region PiTR is best suited for TiDB Cloud Dedicated customers that need region-level disaster recovery without the cost of a continuously running duplicate production footprint.

It is especially relevant for:

• Large SaaS platforms with strict business continuity requirements.
• Multi-tenant systems where regional downtime affects many customers.
• Gaming 그리고 fintech workloads with high write volume.
• Trading or transaction systems that require recent recovery points.
• Customers that need periodic DR drills.
• Multi-cluster customers that need to restore critical clusters by priority.

The ideal fit is a customer that needs minute-level RPO targets, can accept hour-level RTO, and wants a verifiable recovery path at a lower steady-state cost.

Current Scope and Boundaries

The current scope is focused on AWS. GCP and Azure are not covered in this release. CMEK, database-level restore, table-level restore, and arbitrary third-region restore are also out of scope. The restore target must be one of the configured primary or secondary regions.

RPO and RTO numbers should be treated as design targets and reference benchmarks, not contractual SLAs. Actual results depend on workload shape, log volume, backup frequency, object storage behavior, target-region capacity, TiKV topology, instance type, and storage throughput.

After the restored cluster becomes connectable, it might still be rebuilding TiFlash replicas, ADD INDEX changes, statistics, or RocksDB compaction state in the background. The recommended recovery pattern is to bring back critical traffic first, then gradually resume heavier workloads as the cluster reaches full performance readiness.

Region-Level Resilience Without a Second Production Stack

TiDB Cloud Dedicated Cross-Region PiTR gives customers a practical way to survive region-level disasters at a low steady-state cost. It continuously replicates backup data to another region, validates which timestamps are actually recoverable, and restores a new cluster on demand when disaster recovery is required. Dedicated customers gain region-level resilience without permanently operating a second full production stack.

This capability is powered by continuous BR innovation: Physical full restore, PITR restore, compacted SST restore, restore phase splitting, and elastic TiKV parallelism. Together, these capabilities make minute-level RPO targets and tunable hour-level RTO achievable for production-scale TiDB Cloud Dedicated deployments.

For customers running mission-critical workloads on TiDB Cloud Dedicated, Cross-Region PiTR turns disaster recovery into a lower-cost, verifiable, and operationally realistic capability for real region-level failures.

Cross-Region PiTR turns cross-region disaster recovery into a set of decisions you can model: RPO targets, restore cluster sizing, backup frequency, and steady-state cost. Talk to a TiDB expert to find out how to map these variables to your TiDB Cloud Dedicated deployment.