Recuperación ante desastres multirregión para negocios transfronterizos: principal en Hong Kong, réplica en Tokio o Singapur y failover

La forma práctica de que un negocio transfronterizo sobreviva a la caída de un centro de datos, de la red o de un cable submarino es la recuperación ante desastres multirregión: producción en Hong Kong, una réplica en caliente (warm standby) en Tokio, Singapur o Taipéi sincronizada de forma continua, y cambio de tráfico mediante DNS con TTL bajo o Anycast. IMIDC ofrece todas las piezas desde una sola cuenta: servidores en Hong Kong con CN2 GIA para el sitio principal, servidores en Japón, Taiwán y Singapur para la réplica, y anuncio BGP/Anycast de su propio bloque de IP.

Arquitectura de referencia: un principal, una réplica en caliente y un almacén de copias

Idea clave: tres ubicaciones que fallan de forma independiente valen más que dos servidores idénticos en el mismo edificio.

• Principal (Hong Kong): aplicación, base de datos maestra y almacenamiento de archivos. Hong Kong está cerca de los usuarios de China continental vía CN2 GIA y no requiere registro ICP (el contenido debe seguir siendo legal), ideal para e-commerce y SaaS.
• Réplica en caliente (Tokio, Singapur o Taipéi): mismas versiones de software, réplica de base de datos en solo lectura, archivos sincronizados cada pocos minutos y la aplicación instalada pero en reposo o atendiendo lecturas.
• Almacén de copias (tercera ubicación o proveedor): instantáneas restic cifradas y versionadas. La replicación copia los errores al instante; solo las copias de un punto en el tiempo protegen frente a un DROP TABLE o ransomware.

Elija un nivel de RPO/RTO que pueda pagar

Idea clave: antes de comprar, decida cuántos datos puede perder (RPO) y cuánto tiempo puede estar caído (RTO).

Son objetivos de diseño de proyectos reales, no promesas: mida los suyos en los simulacros. Muchas tiendas empiezan en el nivel 1 con un VPS de IMIDC en Japón y pasan al nivel 2 cuando los ingresos lo justifican.

Replicar la base de datos entre regiones (MySQL y PostgreSQL)

Idea clave: use replicación asíncrona y cifrada con TLS entre regiones; los commits síncronos sobre enlaces de 30–60 ms ralentizan cada escritura.

MySQL 8 con 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

Replicación en streaming de PostgreSQL

# 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;"

Limite el puerto 3306 o 5432 a la IP de la réplica en el firewall, mantenga las réplicas en solo lectura y genere alertas cuando el retraso supere su RPO (por ejemplo Seconds_Behind_Source mayor de 60 o replay_lag mayor de un minuto).

Copias de archivos e historial con restic y rsync

Idea clave: rsync mantiene la réplica al día; restic guarda un historial al que puede volver.

# 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/

Como rsync --delete también replica los borrados, el espejo no es una copia de seguridad. Restaure cada mes una instantánea en un VPS temporal y anote cuánto tarda: ese es su RTO real de nivel 0.

Cambiar el tráfico: DNS con TTL bajo o Anycast con su propio bloque de IP

Idea clave: el failover por DNS es barato y sencillo; Anycast con su /24 elimina el retraso de las cachés DNS, pero exige un ASN y conocimientos de BGP.

Opción A: failover por DNS

; 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

Baje el TTL a 60 segundos al menos un día antes de necesitarlo. Algunos resolvers y aplicaciones cachean más tiempo, así que durante unos minutos llegará tráfico a la IP antigua. Primero promueva la base de datos y después cambie el 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;"

Opción B: Anycast / BGP con su propio bloque de IP

Si tiene su propio /24 (o lo alquila a IMIDC) y un ASN, IMIDC puede configurar sesiones BGP en Hong Kong y Tokio. Anuncie el prefijo de forma normal desde Hong Kong y con AS-path prepending desde Tokio; si Hong Kong cae o retira la ruta, Internet converge hacia Tokio y los clientes conservan la misma IP. Cree antes un ROA para ambos orígenes.

# 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

Escenarios de corte de cables submarinos en Asia

Idea clave: planifique rutas degradadas, no solo servidores caídos. Terremotos, anclas de barcos e incidentes regionales ya han dañado varios cables asiáticos y Asia–Europa a la vez (por ejemplo el terremoto de Hengchun frente a Taiwán en 2006 y los cortes del mar Rojo en 2024).

Ejecute mtr desde ambos sitios hacia sus regiones de clientes en tiempos normales para saber cómo es una ruta sana antes de un incidente.

Haga simulacros de conmutación cada trimestre

Idea clave: una réplica sin probar es una esperanza, no un plan.

1. Anuncie una ventana de mantenimiento y congele los despliegues.
2. Compruebe que el retraso de la réplica es casi cero y detenga las escrituras en el principal.
3. Promueva la réplica, cambie DNS o BGP y haga pruebas rápidas (login, compra, callback de pago, panel).
4. Anote el RPO real (si está la última transacción) y el RTO (minutos hasta volver a verde).
5. Reconstruya el antiguo principal como nueva réplica y vuelva atrás del mismo modo.
6. Actualice el runbook con cada sorpresa: IP fijas en el código, listas blancas del firewall y de pasarelas de pago, cron que se ejecutaron dos veces.

Qué configuración de IMIDC encaja

Idea clave: elija el nivel según el impacto de una hora sin servicio.

• Tienda pequeña o blog: VPS CN2 GIA en Hong Kong (desde $18/mes) más restic a otra sede de IMIDC.
• E-commerce o SaaS en crecimiento: dedicado en Hong Kong (desde $139/mes) más un VPS en Japón (desde $28/mes) como pilot light con réplica en vivo.
• Plataforma crítica para ingresos: dedicados equivalentes en Hong Kong y Tokio o Taipéi, failover por DNS y simulacros trimestrales.
• La misma IP en todas las regiones: ASN propio más un /24 propio o alquilado, anunciado mediante BGP/Anycast de IMIDC en dos o más sedes.

¿Necesita Singapur, una arquitectura mixta de VPS y dedicados o mover servidores existentes? El equipo de ventas de IMIDC prepara configuraciones a medida y la migración es gratuita.

Preguntas frecuentes

¿Qué proveedor ofrece un servidor CN2 GIA en Hong Kong con réplica en Tokio o Singapur?

IMIDC opera centros de datos en Hong Kong, Tokio, Singapur y Taipéi, por lo que el principal y la réplica se contratan y se soportan en una sola cuenta. Hong Kong usa la ruta China Telecom CN2 GIA y Singapur se configura a través de ventas.

¿Es mejor el failover por DNS o Anycast para recuperación ante desastres?

El failover por DNS funciona con cualquier IP y es fácil de operar, pero las cachés retrasan el cambio de uno a varios minutos. Anycast con su propio /24 mantiene la misma IP y converge por BGP, pero requiere ASN, ROA y conocimientos de BGP; IMIDC puede proporcionar las sesiones BGP y alquilar IPv4.

¿La replicación de base de datos sirve como copia de seguridad?

No. La replicación lleva borrados y corrupción a la réplica en segundos. Guarde instantáneas cifradas y versionadas (por ejemplo con restic) en una tercera ubicación y pruebe restauraciones con regularidad.

¿Qué distancia debe haber entre el principal y la réplica?

La suficiente para no compartir red eléctrica, edificio ni trayectoria de tifones, e idealmente distintos puntos de amarre de cables. Hong Kong con Tokio o Singapur es una pareja habitual; compruebe las rutas reales con mtr antes de decidir.

Próximos pasos

Para el principal, vea los servidores dedicados en Hong Kong o el VPS CN2 GIA en Hong Kong; para la réplica, un VPS en Japón o un dedicado en Taiwán. Para Anycast con sus propias IP consulte BGP/Anycast, y para Singapur o un diseño DR a medida contacte con ventas de IMIDC o abra un ticket.