Estrategias de DR y RTO/RPO

1) Principios básicos

1. Objetivos anteriores a los fondos. Primero formulamos RTO/RPO y escenarios críticos, luego elegimos la tecnología.
2. Segmentación por importancia. No todos los servicios requieren «oro»; dividir por criticidad empresarial.
3. Los datos son el núcleo del Dr. La consistencia, la replicación, la detección de daños y el punto de recuperación son más importantes que el «hierro».
4. Automatización y verificabilidad. El DR carece de sentido sin IaC, pruebas de retroceso de recuperación y telemetría.
5. Enseñanzas y pruebas. Un plan sin «game day» regular es una ilusión de preparación.
6. Seguridad y cumplimiento. Cifrado, aislamiento, backups WORM/immutable, DPA/jurisdicciones.

2) Términos y correspondencias

RTO - Tiempo desde el momento del evento hasta el restablecimiento del servicio «normal».
RPO es la «edad» del último punto de datos saludable en la recuperación.
RLO (Recovery Level Objective) es un nivel de funcionalidad que está obligado a restaurar (un servicio mínimamente viable).
MTD (Maximum Tolerable Downtime) es el umbral después del cual el negocio sufre daños inaceptables.
RTA/RPA (Actual): tiempo real/punto de recuperación de las prácticas.

Comunicación: RTO ≤ MTD; RPA ≤ RPO. La brecha entre los objetivos y el hecho es un tema de post mortem y mejoras.

3) Clases de estrategias de RD (niveles de preparación)

4) Escenarios contra los que nos defendemos

Pérdida de región/nube/centro de datos (electricista, red, proveedor).
Corrupción de datos/error del operador (eliminación, réplicas «rotas», daño lógico).
Malware/cifrador (ransomware).
Defecto de versión/configuración (salida masiva).
El colapso de la dependencia (KMS, DNS, secretos, proveedor de pagos).
Eventos legales (bloqueos, prohibición de sacar datos de la jurisdicción).

Para cada escenario, especifique RTO/RPO, nivel de DR, playbook, responsables.

5) Estrategias de datos (clave de RPO)

5. 1 Backups

Registros de transacciones completos + incrementales + (para BD).
Almacenamiento inmutable/WORM y copias offline («air-gapped»).
Directorio de backups con metadatos y criptopodescripciones; recuperación de prueba programada.

5. 2 Replicación

Sincrónico (bajo RPO, ↑latentnost, riesgo de propagación de daños).
Asincrónico (bajo impacto en la perforación, RPO> 0; combinar con el detalle del daño).
CDC (Change Data Capture) para replicación en streaming y reconstrucción de estados.

5. 3 Protección contra daños lógicos

Versificación/» puntos en el tiempo» (PITR) con ventana ≥ N días.
Las firmas de invariantes (balances, sumas, chexummas) son el primer detecto de los datos «rotos».
Canales de replicación «lentos» (delay 15-60 min) como búfer contra daños instantáneos.

python def pick_restore_point(pitr, anomaly_signals, max_age):
healthy = [p for p in pitr if not anomaly_signals. after(p. time)]
return max(healthy, key=lambda p: p. time if now()-p. time <= max_age else -1)

6) Aplicación, estado, caché

Staitless Layer - Escalar y reiniciar en cualquier región (imagen/lista/manifiestos en Git).
Estado (DB/caché/kew): la fuente de la verdad es una de DB; las cachés y los índices son sobregenerables.
Idempotencia y re-drive: la reintroducción de eventos es admisible; use outbox/inbox, dedoup y versiones.

7) Red y punto de entrada

GSLB/DNS failover: latency/health-based, TTL corto en la ventana del accidente.
Anycast/L7-proxy: IP única, enrutamiento de salud regional.
Dominios regionales y políticas jurisdiccionales (geo-pinning para PII).
Feilover certificados/KMS: cadenas de repuesto, dual-key.

python if slo_breach("region-a") or health("region-a")==down:
route. shift(traffic, from_="region-a", to="region-b", step=20) # канарим enable_readonly_if_needed()

8) Modelo operativo y automatización

IaC/GitOps: infraestructura de la segunda región = código, implementación «de un solo botón».
Policy as Code: gate «no hay manifiestos DR/backups/alertas - no hay lanzamiento».
Runbooks: instrucciones paso a paso y un «botón rojo» idéntico a ambas regiones.
Secretos: créditos de corta vida, federación OIDC, plan de compromiso/revocación.

rego package dr deny["Missing PITR ≥ 7d"] {
input. db. pitr_window_days < 7
}
deny["No restore test in 30d"] {
now() - input. db. last_restore_test > 3024h
}

9) Ejercicios y pruebas (Días de juego)

Tabla de escenarios: pérdida de DB, datos «rotos», fallo de KMS, caída de la región, límite de egresos repentinos.
Frecuencia: trimestral para misión crítica; cada seis meses para los demás.
Métricas de la enseñanza: RTA/RPA vs objetivos, proporción de pasos automáticos, número de intervenciones manuales, errores de playbook.
Chaos-smoke en las versiones: la degradación de las dependencias no debe «romper» las rutas DR.

T0: cut off the primary database (firewall drop)
T + 2m: GSLB shift 20% of traffic, then 100% at SLO_ok
T + 6m: checking business invariants and lag replication
T + 10m: post-drill: fixing RTA/RPA, playbook improvements

10) Playbucks (patrón canónico)

yaml playbook: "dr-failover-region-a-to-b"
owner: "platform-sre"
rto: "15m"
rpo: "5m"
triggers:
- "health(region-a)==down"
- "slo_breach(payments)"
prechecks:
- "backup_catalog ok; last_restore_test < 30d"
- "pitr_window >= 7d"
steps:
- "Announce incident; open war-room; assign IC"
- "Freeze writes in region-a (flag write_readonly)"
- "Promote db-b to primary; verify replication stopped cleanly"
- "Shift GSLB 20%→50%→100%; monitor p95/error"
- "Enable compensations and re-drive queues"
validation:
- "Business invariants (balances, duplicate_checks)"
- "Synthetic tests green; dashboards stable 30m"
rollback:
- "If db-b unhealthy: revert traffic; engage restore from PITR T-Δ"
comms:
- "Status updates each 15m; external note if SEV1"

11) Métricas de observación DR

Replica lag (sec.), RPO-drift (diferencia entre el objetivo y el RPO real).
Restore SLI: tiempo de recuperación en frío/calor a través de los alrededores.
Cobertura:% de los servicios con playbooks/backups/PITR ≥ N días.
Drill score: proporción de pasos automáticos, distribución RTA, tasa de error.
Inmutabilidad:% de los backups en WORM/air-gapped.
Métricas de eventos: longitud de las colas/velocidad de re-drive después del failover.

12) Costos y compromisos

CapEx/OpEx: el soporte caliente es más barato que Active/Active, pero más caro que Pilot Light.
Egress: la replicación interregional/interparlamentaria cuesta dinero; caché/compresión/agregados locales.
RTO/RPO vs $: cada «nueve» de disponibilidad y un segundo de RPO cuestan varias veces más - alinear con el negocio.
Ventanas verdes: replicación de batch - en relojes baratos/« verdes ».

13) Seguridad y cumplimiento

Cifrado «en reposo» y «en tránsito», dominios KMS separados por región.
Immutable-backups, protección contra ransomware: «3-2-1» (3 copias, 2 medios, 1 offline), MFA-delete.
Jurisdicciones: geo-pinning para PII, localización de backups, Legal Hold sobre TTL.
Accesos en tiempo: roles temporales para operaciones de DR, registro de auditoría.

14) Anti-patrones

«Escribamos un plan más tarde» - DR sin enseñanzas.
Replicación sin protección contra el daño lógico: multiplicará el error de forma migratoria.
Una región de KMS/Secretos - No se puede hacer un failover.
Los backups sin restauraciones regulares son DR «shredinger».
Transacciones sincrónicas estrechamente relacionadas entre regiones - latencia en cascada/caída.
Ninguna priorización: el mismo nivel de DR para todo (caro e inútil).

15) Check-list del arquitecto

1. ¿Definidos RTO/RPO/RLO por servicios y escenarios?
2. Datos clasificados: fuente de la verdad, PITR/ventana, WORM/immutable?
3. ¿Ha seleccionado el nivel DR (Backup/Restore, Pilot, Warm, A/P, A/A) por servicio?
4. Red: GSLB/Anycast, certificados/llaves con stock, banderas «read-only»?
5. Aplicación: ¿idempotencia, outbox/inbox, transacciones compensatorias?
6. IaC/GitOps/Policy as Code: ¿un clic en el rodillo de la segunda región?
7. Enseñanzas: horario, KPI RTA/RPA, actividades de post-aprendizaje?
8. Monitoreo: lag, RPO-drift, restore-SLI, drill-score, backups inmutables?
9. Seguridad/Cumplimiento: KMS dominios, jurisdicciones, Legal Hold?
10. Costo: egresos del presupuesto, ventanas «verdes», nivel económicamente válido?

16) Mini recetas y sketches

16. 1 PITR para Postgres (idea):

bash base backup daily + WAL archive pg_basebackup -D/backups/base/$ (date +% F)
archive_command='aws s3 cp %p s3://bucket/wal/%f --sse'
restore pg_restore --time "2025-10-31 13:21:00Z"...

16. 2 Protección contra daños lógicos (réplica retrasada):

yaml replication:
mode: async apply_delay: "30m" # window to roll back on corruption

16. 3 Cambio de tráfico (pseudo-API GSLB):

bash gslb set-weight api. example. com region-a 0 gslb set-weight api. example. com region-b 100

16. 4 Verificación de invariantes después del Feilover (pseudocódigo):

python assert total_balance(all_accounts) == snapshot_total assert no_duplicates(events_since(t_failover))

El DR es la capacidad de tomar decisiones técnicas y organizativas más rápido que el daño creciente. Identifique RTO/RPO realistas, elija un nivel de preparación suficiente, automatice la infraestructura y las verificaciones, entrene regularmente y mida los RTA/RPA reales. Entonces el accidente no se convertirá en un desastre, sino en un incidente manejable con un resultado previsible.