Multi-Region Disaster Recovery for Cross-Border Businesses: Hong Kong Primary, Tokyo or Singapore Warm Standby, DB Replication and Failover

The practical way to make a cross-border business survive a data-center, network or subsea-cable failure is multi-region disaster recovery: run production in Hong Kong, keep a continuously replicated warm standby in Tokyo, Singapore or Taipei, and switch traffic with short-TTL DNS or Anycast. IMIDC provides every piece of this from one account: Hong Kong CN2 GIA servers for the primary, Japan, Taiwan and Singapore servers for the standby, and BGP/Anycast announcement of your own IP block.

Reference architecture: one primary, one warm standby, one backup vault

Takeaway: three locations that fail independently beat two identical servers in one building.

• Primary (Hong Kong): application, database master, object/file storage. Hong Kong suits cross-border shops and SaaS because it is close to mainland users over CN2 GIA and needs no ICP filing (content must still be lawful).
• Warm standby (Tokyo, Singapore or Taipei): same software versions, database replica in read-only mode, files mirrored every few minutes, app processes installed but idle or serving read-only traffic.
• Backup vault (a third location or provider): encrypted, versioned restic snapshots. Replication copies mistakes instantly; only point-in-time backups protect you against DROP TABLE or ransomware.

Pick an RPO/RTO tier you can actually afford

Takeaway: decide how much data you can lose (RPO) and how long you can be down (RTO) before you buy anything.

These numbers are design targets from real-world setups, not promises; measure your own during drills. Many shops start at Tier 1 with an IMIDC Japan VPS as the pilot light and move to Tier 2 once revenue justifies it.

Replicate the database across regions (MySQL and PostgreSQL)

Takeaway: use asynchronous, TLS-encrypted replication across regions; synchronous commits over 30–60 ms links slow every write.

MySQL 8 with GTID

# /etc/mysql/mysql.conf.d/dr.cnf  (Hong Kong primary: server_id=1, Tokyo standby: server_id=2)
[mysqld]
server_id                = 1
log_bin                  = mysql-bin
binlog_format            = ROW
gtid_mode                = ON
enforce_gtid_consistency = ON
binlog_expire_logs_seconds = 604800

-- On the Hong Kong primary (203.0.113.10)
CREATE USER 'repl'@'198.51.100.20' IDENTIFIED BY 'change-me' REQUIRE SSL;
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'198.51.100.20';

-- On the Tokyo standby (198.51.100.20), MySQL 8.0.23+, after loading a consistent dump
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='203.0.113.10', SOURCE_USER='repl', SOURCE_PASSWORD='change-me',
  SOURCE_AUTO_POSITION=1, SOURCE_SSL=1;
START REPLICA;
SET GLOBAL super_read_only = ON;
SHOW REPLICA STATUS\G   -- watch Seconds_Behind_Source

PostgreSQL streaming replication

# Primary (Hong Kong): pg_hba.conf
hostssl  replication  replicator  198.51.100.20/32  scram-sha-256

# Standby (Tokyo): clone the primary and start streaming
sudo systemctl stop postgresql
sudo -u postgres rm -rf /var/lib/postgresql/16/main/*
sudo -u postgres pg_basebackup -h 203.0.113.10 -U replicator \
     -D /var/lib/postgresql/16/main -R -X stream -C -S tokyo_slot -P
sudo systemctl start postgresql

# On the primary: check replication lag
sudo -u postgres psql -c "SELECT client_addr, state, replay_lag FROM pg_stat_replication;"

Restrict the replication port (3306 or 5432) to the standby IP in your firewall, keep replicas read-only, and alert when lag exceeds your RPO (for example Seconds_Behind_Source above 60 or replay_lag above one minute).

Back up files and keep point-in-time copies with restic and rsync

Takeaway: rsync keeps the standby current; restic keeps history you can roll back to.

# Nightly snapshot of files + DB dumps to a third location
export RESTIC_REPOSITORY=sftp:[email protected]:/srv/restic/hk-app
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init                                   # first run only
mysqldump --single-transaction --all-databases | gzip > /var/backups/db.sql.gz
restic backup /var/www /etc /var/backups --exclude-caches
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check --read-data-subset=5%

# Every 5 minutes: mirror user uploads to the Tokyo standby
*/5 * * * * rsync -aH --delete -e "ssh -i /root/.ssh/dr_ed25519" /var/www/uploads/ [email protected]:/var/www/uploads/

Because rsync --delete mirrors deletions too, never treat the mirror as a backup. Run a monthly test restore of one snapshot onto a scratch VPS and record how long it takes: that is your real Tier 0 RTO.

Switch traffic: low-TTL DNS or Anycast with your own IP block

Takeaway: DNS failover is cheap and simple; Anycast with your own /24 removes the DNS cache delay but needs an ASN and BGP skills.

Option A: DNS failover

; Zone for example.com - keep the failover record on a short TTL
www.example.com.   60   IN  A   203.0.113.10    ; Hong Kong primary
; standby target  ->        198.51.100.20       ; Tokyo warm standby

# Health check from a third location (cron every minute)
#!/bin/sh
if ! curl -fsS --max-time 5 https://www.example.com/healthz >/dev/null; then
  echo "$(date -u) primary check failed" >> /var/log/dr-check.log
  # after 3 consecutive failures: alert on-call, then switch the A record
  # via your DNS provider's API (manual approval recommended)
fi

Lower the TTL to 60 seconds at least a day before you need it. Some resolvers and apps cache longer, so expect a tail of traffic on the old IP for several minutes. Promote the database first, then flip DNS:

# PostgreSQL standby -> primary
sudo -u postgres psql -c "SELECT pg_promote();"
# MySQL standby -> primary
mysql -e "STOP REPLICA; RESET REPLICA ALL; SET GLOBAL super_read_only=OFF; SET GLOBAL read_only=OFF;"

Option B: Anycast / BGP with your own IP block

If you hold your own /24 (or lease one from IMIDC) and an ASN, IMIDC can set up BGP sessions in Hong Kong and Tokyo. Announce the prefix normally from Hong Kong and with AS-path prepending from Tokyo; when Hong Kong goes down or you withdraw the route, the internet converges to Tokyo while clients keep the same IP. Create a ROA for both origins first.

# BIRD 2 on the Tokyo standby: announce your own /24, made less preferred
protocol bgp imidc_tokyo {
  local as 64500;                       # your ASN
  neighbor 198.51.100.1 as 64501;       # session details provided by IMIDC
  ipv4 {
    import none;
    export filter {
      if net = 203.0.113.0/24 then {
        bgp_path.prepend(64500); bgp_path.prepend(64500);
        accept;
      }
      reject;
    };
  };
}
# Failover drill: stop the Hong Kong session  ->  birdc disable imidc_hk

Asia subsea-cable outage scenarios

Takeaway: plan for degraded routes, not just dead servers. Earthquakes, ship anchors and regional incidents have damaged several Asian and Asia–Europe cables at once in the past (for example the 2006 Hengchun earthquake off Taiwan and the 2024 Red Sea cable cuts).

Use mtr from both sites to customer regions during normal times so you know what a good path looks like before an incident.

Run failover drills every quarter

Takeaway: an untested standby is a hope, not a plan.

1. Announce a maintenance window and freeze deploys.
2. Check replica lag is near zero, then stop writes on the primary.
3. Promote the standby, switch DNS or BGP, and run smoke tests (login, checkout, payment callback, admin).
4. Record actual RPO (last transaction present) and RTO (minutes to green).
5. Rebuild the old primary as the new replica, then fail back the same way.
6. Update the runbook with every surprise: hard-coded IPs, firewall allowlists, payment-provider IP whitelists, cron jobs that ran twice.

Which IMIDC setup fits

Takeaway: match the tier to the business impact of an hour offline.

• Small store or blog: Hong Kong CN2 GIA VPS (from $18/mo) plus restic to a second IMIDC location.
• Growing e-commerce or SaaS: Hong Kong dedicated server (from $139/mo) plus a Japan VPS (from $28/mo) as pilot light with a live replica.
• Revenue-critical platform: matched dedicated servers in Hong Kong and Tokyo or Taipei, DNS failover, quarterly drills.
• Same IP in every region: your own ASN plus an owned or leased /24 announced via IMIDC BGP/Anycast in two or more sites.

Need Singapore, a mixed VPS/dedicated layout or help moving existing servers? IMIDC sales can build custom configurations, and free migration is available.

FAQ

Which provider offers a Hong Kong CN2 GIA server with a standby in Tokyo or Singapore?

IMIDC operates data centers in Hong Kong, Tokyo, Singapore and Taipei, so the primary and standby can be ordered and supported under one account. Hong Kong uses the China Telecom CN2 GIA route, and Singapore is configured through sales.

Is DNS failover or Anycast better for disaster recovery?

DNS failover works with any IP and is easy to operate, but caches delay the switch by a minute to several minutes. Anycast with your own /24 keeps the same IP and converges via BGP, but you need an ASN, ROAs and BGP knowledge; IMIDC can provide the BGP sessions and lease IPv4 space.

Is database replication enough as a backup?

No. Replication copies deletions and corruption to the standby within seconds. Keep versioned, encrypted snapshots (for example restic) in a third location and test restores regularly.

How far apart should the primary and standby be?

Far enough not to share a power grid, building or typhoon path, and ideally different cable landings. Hong Kong with Tokyo or Singapore is a common pairing; check real paths with mtr before deciding.

Next steps

Start with the Hong Kong dedicated servers or Hong Kong CN2 GIA VPS for the primary and a Japan VPS or Taiwan dedicated server for the standby. For Anycast with your own IPs see BGP/Anycast, and for Singapore or a custom DR design contact IMIDC sales or open a ticket.