The core of database disaster recovery is not merely "whether a backup exists," but rather: "in the worst-case scenario, how quickly can the business recover, and how much data might be lost?" These questions are quantified by two key metrics: RTO (Recovery Time Objective) and RPO (Recovery Point Objective). For operations deployed on servers in Japan, planning for RPO and RTO involves an additional, practical constraint: Japan is highly prone to earthquakes. While cross-regional disaster recovery—typically between Tokyo and Osaka—is a common architectural approach, factors such as network latency between these locations, database replication modes, and failover mechanisms directly determine whether these targets can actually be met.
First, let’s clarify what RPO and RTO actually measure.
RPO (Recovery Point Objective) measures the maximum amount of data loss a business can tolerate, expressed in terms of time. An RPO of 0 means zero data loss, while an RPO of 15 minutes means that, in the event of a failure, up to 15 minutes' worth of recent data could be lost. RTO (Recovery Time Objective) measures the maximum acceptable duration for a business to fully recover following a failure. This encompasses the entire process: detecting the failure, making the decision to switch over, promoting the database, reconnecting applications, and verifying that the system is operational.
The relationship between the two can be illustrated with a simple example: if the RPO is 5 minutes and the RTO is 30 minutes, it means that in the event of a failure, you can tolerate the loss of up to 5 minutes of recent data, and the business must be fully restored and available again within 30 minutes. RPO is determined by backup frequency or replication mode, while RTO is determined by the failover process and the responsiveness of the underlying infrastructure.
It is a well-documented fact that there is often a significant gap between design and actual performance. According to the *2025 White Paper on the Development of China’s Disaster Recovery Industry* (published by the China Academy of Information and Communications Technology), fewer than 40% of enterprises conduct a full-scale disaster recovery drill at least once a year—and an even smaller percentage succeed on their first attempt. In one instance, a bank discovered during a drill that while its dual-site (intra-city) disaster recovery setup was designed for an RTO of 10 seconds, the actual failover took 47 seconds. The culprit? A single, overlooked firewall rule that had blocked the "heartbeat" signal between the primary and standby systems. The reliability of disaster recovery (DR) can only be proven through drills; it cannot be guaranteed by design documentation alone.
RPO/RTO Tiered Planning in the Japanese Context
In the Japanese market, database disaster recovery is typically designed around a cross-region pairing between Tokyo (Japan East) and Osaka (Japan West). For Oracle Autonomous Database, Japan East (Tokyo/Saitama) and Japan West (Osaka) are officially supported as a DR pair; using Data Guard in synchronous mode, the RPO can be kept under one minute, with support for automatic failover. In a reference implementation by NEC using Oracle Active Data Guard between Tokyo and Osaka, an RPO of 0 and an RTO of less than 2 minutes were achieved by leveraging Active Data Guard’s "Fast-Start Failover" in conjunction with DNS traffic management.
However, not all business operations require—or can justify the investment for—such a high level of protection. A more pragmatic approach involves tiered planning based on business criticality, avoiding both "over-investment" (applying the highest standard to every system) and "under-investment" (settling for inadequate protection across the board).
Core Business (e.g., financial transactions, payments, core e-commerce orders): The RPO should be planned for 0 to 1 minute, with an RTO of under 5 minutes. The architecture typically involves a dual-region deployment (Tokyo and Osaka), utilizing synchronous or quasi-synchronous database replication (such as MySQL semi-synchronous replication or PostgreSQL synchronous streaming replication) combined with an automatic failover mechanism. While this tier is the most cost-sensitive, it is also the area where a failure carries the highest potential cost.
Important Business (e.g., corporate websites, SaaS platforms, cross-border e-commerce backends): An RPO of 5 to 15 minutes is acceptable, with an RTO planned between 30 minutes and 2 hours. The architecture primarily relies on asynchronous replication supplemented by scheduled backups. At the database level, Point-in-Time Recovery (PITR) is enabled via binary logs (binlog) or Write-Ahead Logs (WAL), with the remote site maintaining a replication lag measured in minutes. The failover process may include a manual confirmation step, provided that the detection and decision-making workflows are clearly defined in advance.
General Business and Internal Systems: The RPO can be relaxed to 1 hour, with an RTO of 4 to 8 hours. This approach relies on daily full backups combined with hourly incremental archives, supplemented by snapshot-based recovery. The primary objective at this level is "recoverability" rather than "rapid recovery."
Drills: RPO and RTO are not calculated—they are determined through execution.
The core purpose of a drill is not to "prove the plan is flawless," but to proactively uncover gaps between design and execution. Data from the China Academy of Information and Communications Technology (CAICT) indicates that most enterprises cannot pass a drill on their first attempt; such gaps are the norm.
Principles for a drill environment: Never conduct drills directly on production databases. Use a replica or an isolated, dedicated drill environment to ensure production operations remain unaffected. The goal of a drill is not to showcase technical prowess, but to verify two things: whether the backup files can truly be used to restore a functional database, and the actual time required for each step of the failover or recovery process.
Taking MySQL as an example, here is an actionable database recovery drill workflow for the scenario of "restoring a complete instance from a backup":
Step 1: Simulate total database corruption. Shut down the database process and rename the data directory (rather than deleting it outright) to emulate extreme scenarios, such as corrupted data blocks or accidental file deletion.
Step 2: Copy and decompress the backup. Transfer the backup files to the target environment. If compression (e.g., zstd) was used, decompress the files—ensuring beforehand that the necessary decompression tools are installed.
Step 3: Prepare the backup. Use the `--prepare` parameter in `xtrabackup` to roll back uncommitted transactions and roll forward committed transactions, bringing the backup files into a consistent state suitable for recovery.
Step 4: Restore data and launch the instance. Create the target data directory and configuration files, restore the "prepared" backup into the target directory (using `move-back` or `copy-back`), add the necessary log files, adjust file permissions, and start the database instance.
Step 5: Verify and measure time. Track the entire duration from the moment the "failure" is declared until the database is ready for read/write operations; this duration represents the actual RTO. Simultaneously, determine the time gap between the restored data's timestamp and the moment the failure occurred—this represents the actual RPO. Compare these figures against your design targets; any discrepancies indicate where optimizations should be focused. Drill Frequency and Format: It is recommended to conduct a tabletop exercise (simulating processes and role assignments) at least once per quarter, and a full-scale recovery drill (executing the actual recovery steps) at least once every six months. Drill plans should clearly define scenarios, participants, rollback procedures, and criteria for success.
Why Infrastructure Stability Is the Implicit Prerequisite for RPO/RTO
While the planning and drill processes for RPO (Recovery Point Objective) and RTO (Recovery Time Objective) can be meticulously documented and scripted, one variable is frequently underestimated: the stability of the network infrastructure that supports database replication links and backup data transfers.
In asynchronous replication scenarios, the primary database’s binary logs (binlogs) must be continuously transmitted to the secondary (replica) database. If the cross-border link—for instance, between Tokyo and a management console in mainland China—experiences significant packet loss during evening peak hours, operations staff may be unable to log in promptly to monitor replication lag. The replication link itself could even be interrupted by network instability, causing the RPO to expand unnoticed. During recovery drills, the cross-region transfer of backup files also relies on the network; if backup download speeds are limited to only a few dozen KB/s, an "RTO of 30 minutes" becomes nothing more than a promise on paper.
The Tokyo node addresses this challenge at the infrastructure level. It utilizes an optimized network route back to mainland China—serving all three major domestic carriers—with latency consistently around 50ms for coastal regions and 70–90ms for inland areas. Bandwidth utilization approaches the theoretical peak, maintaining a sustained throughput of approximately 185 Mbps. This ensures that when managing the Tokyo-based database, monitoring replication status, or executing recovery operations from within China, connections remain stable without frequent timeouts caused by cross-border link fluctuations. Consequently, the time window required for fault detection and failover decision-making is not unnecessarily extended by network issues.
Regarding storage and data protection, Jtti supports one-click snapshot backups. For disaster recovery scenarios—such as creating a restore point before a major system change or rapidly rolling back to a known, stable state—snapshots offer a faster path to recovery (shorter RTO) compared to file-by-file restoration. Furthermore, the inclusion of dedicated bandwidth as a standard feature across the entire product line ensures that backup transfers and replication traffic are not queued or delayed due to "noisy neighbors" consuming shared bandwidth, making the latency of asynchronous replication far more predictable. A "lifetime recurring discount" policy (which applies to renewals as well) ensures that the costs of maintaining a cross-region disaster recovery (DR) architecture remain fully controllable. Since DR requires ongoing investment, the predictability of costs is just as critical as the technical reliability of the solution.
The true value of RPO (Recovery Point Objective) and RTO (Recovery Time Objective) lies not in the figures stated in a proposal, but in the actual results achieved during drills. The process should begin by clearly defining objectives based on business criticality, followed by conducting realistic recovery drills to verify the time required for each stage. Finally, by leveraging a stable network and a reliable storage foundation, the gap between the "designed" values and the "actual" outcomes can be minimized.
