How to Balance Cost, Recovery Speed, and Data Protection Across Clouds
1. Business continuity challenges in the cloud era
As digital transformation advances, business continuity has evolved from a technical concern into a business strategy. An hour of downtime during a major e-commerce promotion can result in millions in lost revenue. A system outage at a financial institution can lead to substantial regulatory penalties. Service unavailability for a SaaS provider can cause customers to leave in large numbers. Data is the core asset of these businesses, and a database’s disaster recovery capabilities directly determine whether the business can survive an extreme event.
Many enterprises deploy all their resources with a single cloud provider. This architecture carries clear risks: no cloud provider can provide 100% availability, and regional failures or network outages can occur. Excessive dependence on a single provider also weakens an enterprise’s position in commercial negotiations and limits architectural evolution. Regulations in some industries explicitly prohibit storing data in only one location.
It is important to distinguish high availability from disaster recovery. High availability addresses individual failures. If a node fails, the system automatically switches over and continues serving requests. With its three-replica architecture based on the Paxos consensus protocol, OceanBase provides automatic failover with RPO = 0 and RTO < 8s for a single-node failure. Disaster recovery addresses catastrophic failures, such as a power outage affecting an entire data center or the unavailability of an entire region. These events require a disaster recovery architecture that spans data centers, regions, or even cloud providers.
This article focuses on disaster recovery and systematically explains OceanBase’s multi-tier disaster recovery solutions.
2. Disaster recovery concepts and architectures
Three core metrics are used to evaluate a disaster recovery solution:
RTO (Recovery Time Objective): the maximum acceptable time between a failure and service recovery. Core financial systems typically require RTO < 30 seconds, whereas general-purpose systems may accept recovery within hours.
RPO (Recovery Point Objective): the maximum acceptable amount of data loss. Core financial transactions require RPO = 0, meaning no data loss, whereas development and test environments may accept hours of data loss.
SLA (Service Level Agreement): an enterprise’s commitment to the availability of a business system. A disaster recovery architecture is designed to meet the RTO and RPO requirements defined in the SLA.
Overview of OceanBase disaster recovery architectures
OceanBase provides a range of disaster recovery solutions, from basic protection to the highest level of protection. Each solution has different priorities in recovery speed, data protection, cost, and technical complexity:
OceanBase disaster recovery solutions have three tiers:
Multi-replica disaster recovery within a single cluster: uses the Paxos protocol to protect against node-level and data-center-level failures.
Cross-region primary/standby databases: protect against region-level failures across cities.
Cross-cloud active-active deployment: provides the highest level of disaster recovery protection.
These solutions do not replace one another. Instead, they provide progressively stronger protection. Many enterprises adopt a tiered disaster recovery strategy based on business criticality: active-active deployment for core systems, primary/standby databases for important systems, and backup-based recovery for general-purpose systems. This approach balances protection and cost.
3. How to choose a disaster recovery solution
There is no universally best disaster recovery solution. The right choice depends on the primary requirements of each business scenario:
Startups and non-critical systems: If cost is the priority and recovery within hours is acceptable, choose backup-based recovery.
Online businesses such as online education and e-commerce: If recovery within minutes and cost-effectiveness are required, choose cross-region primary/standby databases.
Fintech and core transaction systems: If regulations require switchover within seconds and no data loss, choose cross-cloud active-active deployment.
The following sections explain the technical principles of each solution.
Backup-based recovery
The core approach of backup-based recovery is to create backups regularly and restore them when needed. It does not provide real-time protection, but it offers basic data protection at the lowest cost.
OceanBase Cloud provides comprehensive backup and restore capabilities with the following core mechanisms:
Backup types:
Physical backup: captures baseline data at a specific compaction point and combines it with subsequent incremental Commit Log records to physically restore the entire database state.
Logical backup: backs up logical data structures such as tables, indexes, views, and stored procedures. It is highly selective and supports granular backups by database, table, or tenant.
Backup policy: You can configure the data backup schedule by week or month, the backup time, preferably during off-peak hours, and a retention period from 2 to 7200 days. Log backup is enabled automatically to support point-in-time recovery (PITR).
Multi-tier backup protection:Local level-1 backup: meets routine recovery requirements.
Archive backup: supports long-term retention and is suitable for historical data archiving.
Remote backup: provides cross-region data protection.
Sparse backup: balances recovery capability and storage cost.
Recovery capability: supports recovery to any point in time.
Use cases: development and test environments, internal management systems, historical data archiving, and a fallback that complements more advanced disaster recovery solutions.
Cross-region primary/standby databases
The core of cross-cloud primary/standby databases is that the primary database continuously serves traffic while the standby database synchronizes data in real time. The primary database handles business reads and writes, and data synchronization keeps the standby database consistent with the primary database. If the primary database fails, the standby database can take over within minutes, providing disaster recovery across cloud providers.
The cross-cloud primary/standby database feature in OceanBase Cloud provides disaster recovery through the following core mechanisms:
Global address: A cross-cloud primary/standby deployment provides a unified connection address that normally points to the primary database. After a primary failure triggers a switchover, the global address automatically resolves to the standby database, which becomes the new primary. Applications can resume access without changing their connection addresses, substantially reducing the changes required at the application layer.
Two data synchronization methods: Cross-cloud primary/standby databases support direct network connections and log archiving to meet different business requirements:
Direct network connection: Establishes connectivity between the primary and standby databases through a VPC network, a dedicated line, or the public Internet. The Log Transport Service transfers transaction logs to the standby database in real time. The Log Replay Service then applies the logs to the in-memory MemStore, enabling primary/standby synchronization with millisecond-level latency.
Log archiving: The primary database periodically archives transaction logs to Object Storage Service (OSS). The standby database reads the archived logs from OSS and applies them locally. This method is suitable for cost-sensitive business scenarios that can tolerate some latency.
Two architecture modes:One primary and one standby: A standard disaster recovery architecture with the primary database deployed on cloud A and the standby database on cloud B.
One primary and multiple standbys: Provides greater disaster recovery redundancy and can meet disaster recovery requirements across multiple regions.
Two switchover capabilities:Disaster recovery failover: After the primary database fails, the system automatically redirects business traffic to the standby database. Under normal conditions, the standby database does not serve business traffic and is reserved for disaster recovery. After the failure, the global address resolution is updated and the standby database takes over all read and write requests.
Primary/standby switchover: In a planned switchover, the standby database quickly takes over and becomes the new primary, allowing the business to resume without requiring customer intervention.
Both types of switchover use the global address to route traffic automatically.
Use cases: online services that are sensitive to interruptions, such as online education and e-commerce; core enterprise ERP and CRM systems; systems that require an RTO measured in minutes but not seconds; and financial or insurance institutions that require cross-region disaster recovery.
Cross-cloud active-active deployment
The core value of cross-cloud active-active deployment is that two cloud environments serve business traffic concurrently, with transparent failover if one environment fails. OceanBase Cloud supports instance deployment on five major cloud providers: Alibaba Cloud, Tencent Cloud, Huawei Cloud, AWS, and GCP. This provides the foundation for cross-cloud active-active deployment. Unlike a primary/standby architecture, both data centers in an active-active architecture process read and write requests. Real-time bidirectional synchronization keeps their data consistent. If one cloud environment fails, the other takes over all business traffic without application awareness. For services with extremely strict continuity requirements, such as financial transactions, online payments, and real-time communications, active-active deployment is effectively the only viable choice.
OceanBase Cloud optimizes its cross-cloud active-active architecture at three levels: cross-cloud networking, data synchronization, and conflict handling.
Managed cross-cloud network gateways: In a cross-cloud scenario, networks on different clouds must be connected through dedicated lines, the public Internet, cloud enterprise networks, or similar methods. OceanBase Cloud provides managed cross-cloud gateway services. The platform constructs, monitors, and maintains the cross-cloud network. You select the cloud providers and regions of the source and destination, and the data synchronization task automatically determines the required network service. You do not need to manage the implementation details of the cross-cloud network.
Localized deployment of data transfer components: To mitigate the impact of cross-cloud network latency on transfer performance, OceanBase Cloud adjusts the deployment of its underlying components. The data log parsing component is deployed in the source cloud and region, while the data writing component is deployed in the destination region. The source-side parsing component filters out most data that does not need to be synchronized. Placing the writer close to the destination avoids write performance degradation caused by network latency.
Encrypted data transmission: Cross-cloud gateways use AES-128-GCM to encrypt data in transit at the network layer. Session keys between gateways are transmitted through a secure control tunnel on the private OMS network and rotated regularly, protecting cross-cloud data transmission.
Bidirectional synchronization and loop prevention: An active-active architecture requires both data centers to accept reads and writes, which requires real-time bidirectional synchronization. OceanBase Cloud data links support heterogeneous bidirectional synchronization among MySQL, Oracle, and OceanBase. A central challenge is synchronization loops: after data written at one endpoint is synchronized to the other, the resulting logs could be synchronized back to the first endpoint. OceanBase Cloud uses different loop-prevention strategies for different databases:
For MySQL and Oracle, a transaction table records data generated by synchronization. The log parser checks this table and filters out the recorded data before parsing the logs.
For OceanBase, the writing component uses thread_id to identify synchronized data, which the parser automatically discards.
Real-time conflict detection: A conflict can occur when both data centers write or update the same record, identified by the same unique key. OceanBase Cloud active-active replication links detect conflicting data in real time and process it according to a predefined policy: overwrite the destination data, ignore the conflict and retain the destination data, or record the conflict for manual handling. You can download conflict records to help identify the root cause.
Cross-cloud active-active deployment builds on the Paxos-based high availability that OceanBase Cloud provides within a single cloud. The three-replica Paxos architecture provides automatic failover for node-level failures within one cloud, with RPO = 0 and RTO < 8s. Cross-cloud active-active deployment further protects against failures at the cloud-provider level. The two mechanisms complement each other and form a complete high-availability architecture from the node level to the cloud level.
Use cases: core financial transactions, payment and settlement systems, online payments, real-time communications, and other businesses that require uninterrupted service, as well as regulated financial institutions that must meet cross-cloud disaster recovery requirements.
4. Summary and recommendations
Each of the three disaster recovery solutions serves a different purpose. Backup-based recovery provides basic protection at the lowest cost and is suitable when cost is the priority. Cross-region primary/standby databases provide reliable protection at a moderate cost and offer a balance between cost and recovery capability. Cross-cloud active-active deployment uses the resources required to provide the highest level of protection and meet mandatory compliance requirements.
Consider the following recommendations when implementing a solution:
Use tiered protection instead of a single approach for all systems: Use active-active deployment for core systems, primary/standby databases for important systems, and backup-based recovery for general-purpose systems.
Disaster recovery is not the same as backup: Disaster recovery addresses site-level failures, whereas backups address logical data errors. Backups remain necessary even with an active-active deployment.
Conduct regular drills: A disaster recovery solution that has not been tested remains viable only in theory.
Start with a simple solution and evolve gradually: You can begin with backup-based recovery and upgrade to primary/standby databases and then active-active deployment as the business grows.
With a distributed architecture based on the Paxos consensus protocol, tenant-level primary/standby database technology, and a complete solution portfolio spanning backup-based recovery through active-active deployment, OceanBase provides enterprises with multi-tier disaster recovery options that range from simple to complex and from economical to maximum protection.
Top comments (0)