Disaster Recovery и cold-backups

Resumen breve

DR es la capacidad de restaurar las funciones del negocio después de un accidente importante. Cold-backups es la «última línea de defensa»: copias inmutables/aisladas, aptas para la recuperación cuando el sitio está completamente endurecido o comprometido. La estrategia gira en torno a la RTO/RPO, la priorización de sistemas, los ejercicios anuales de DR y una estricta disciplina operativa (catálogos, claves, validaciones).

Términos y objetivos

RPO (Recovery Point Objective) - Pérdida máxima permitida de datos (por ejemplo, ≤ 15 min).
RTO (Recovery Time Objective) - tiempo de recuperación máximo permitido (por ejemplo, ≤ 2 h).
Black-start - recuperación «desde cero»: hierro/clúster/secretos/datos/DNS.
Air-gap es el aislamiento físico/lógico de las copias (cinta/cuenta deshabilitada/medio offline).
Immutability (WORM): almacenamiento inmutable (cinta/objeto con Lock/Retention).

Niveles de preparación de DR

Cold Site: la infraestructura no está/está congelada; RTO: horas-días; CAPEX/OPEX más barato.
Warm Site - plantillas/imágenes/servicios parcialmente terminados; RTO: docenas de minutos-horas.
Hot Site - réplicas activas; RTO: minutos; más caro y más difícil.
Híbrido: kernel → hot/warm, todo lo demás → cold (con prioridad en el inicio).

Donde los backups cold son indispensables

Cifrado masivo/compromiso de dominio.
Corrupción de datos que se ha ido a todas las réplicas.
Pérdida de la región/centro de datos, fuerza mayor (incendio, inundación).
Eliminación intencional/sabotaje de cuentas privilegiadas.

Topología cold-backups

1. Clases de almacenamiento/medios

Cintas (LTO-8/9): barato, aire-gap por defecto, alta capacidad, acceso secuencial.
Unidades offline/NAS: «cajas fuertes», se conectan sólo a la ventana de respaldo/restauración.
Clases de objetos archivados (Glacier-like): bajo precio de almacenamiento, mayor tiempo de extracción.

2. Ubicación

Otro sitio/región; otro proveedor/cuenta; claves/administradores individuales.

3. Immutabelnost

Cintas WORM/Object Lock (Compliance/Governance) con retoque y Legal Hold.

Política 3-2-1-1-0 (con enfoque en cold)

3 copias de datos (prod + copia de seguridad local + offsite).
2 medios diferentes (disco/cinta/objeto).
1 offsite (otro sitio/nube).
1 inmutable (WORM/air-gap).
0 errores de comprobación (checksum/prueba de recuperación periódica).

Directorios, metadatos y controles de integridad

Directorio de backups: donde, cuando, versión, llaves, cantidad de cheques, fecha de vencimiento.
Catálogo de activos: servicio → dependencia → volumen/baquetas → prioridad.
Checksums y manifest-files: conciliación de escritura y recuperación.
Archivos canarios: restore regular para el niño temprano de problemas de medios.

Cifrado y claves

Cifrado en reposo (cinta/objeto) y en vuelo (copia).
KMS/Vault con control dual, cajas fuertes fuera de línea para llaves maestras, rotación.
Claves separadas para prod/backups/archivos (minimización del radio blast).
Proceso de acceso a claves documentado en DR (requisitos, roles, registro).

Plan de DR: prioridad y secuencia

1. Identificación y acceso: IdP (zona mínima), Vault/KMS, núcleo de red.

2. Datos y planos de control: etcd K8s, confites, secretos, registros de imágenes, artefactos de deployes.

3. BD/billetera transaccional: registros + últimos full/incremental.

4. Pasarelas de pago/integración: claves, certificados, IP/DNS.

5. Web/api-frentes: lanzamiento canario, contenido estático del objeto.

6. Análisis/informes: cuando el núcleo está terminado.

1. Infraestructura: red, DNS/Anycast, núcleos IAM, imágenes básicas/clúster.

2. Secretos/certificados: restaurar Vault/KMS de backup cold, distribuir secretos bootstrap.

3. Plano de control: etcd/Control Plane/mayúsculas/minúsculas/repositorios.

4. Datos: implementar la DB de cold-backup + PITR de los registros (por RPO).

5. Aplicaciones: ejecutar dependencias de árbol, calentar caché/CDN.

6. Pruebas y validación: muestras de salud, consistencia, sumas de control.

7. Cambio de tráfico: DNS/enrutamiento/balanceadores (paso a paso/canario).

8. Post-verificación: sin fugas/deudas, lógica y acto de DR.

Procedimientos cold-restore (típicos)

Cintas: inventario, descarga, streams paralelos, archivos de mapa → directorios → tasky de recuperación; tomando en cuenta el tiempo de búsqueda y rebobinado.
Clase de archivo: solicitud de extracción (minutes→hours), staging en almacenamiento en caliente, recuperación por manifiesto.
Unidades offline: conexión read-only, comprobaciones de checksum → copia.
Práctica: «sandbox» aislado para la recuperación, luego transferido al entorno prod.

Comunicaciones y org. estructura con DR

Роли: Incident Commander, Tech Lead (Infra), DB Lead, App Lead, Comms, Security.
Canales: backup (fuera del dominio corporativo), voz/chat, SecureDocs.
Plantillas de mensajes: clientes/socios/reguladores; la frecuencia de los apdates; una sola «fuente de verdad».
Registro único de eventos: línea de tiempo, soluciones, propietarios.

DNS, redes y tráfico

Split-brain-protection: indicadores «modo DR» en la configuración; feature-flags para una funcionalidad limitada.
Estrategia DNS: bajo TTL por adelantado, proveedor de DNS independiente; cambio por etapas A/AAAA/CNAME, calentamiento CDN.
Enrutamiento: Anycast/Geo, anuncio BGP desde el sitio DR; Las ACL/firewols se superponen desde IaC.

SLO para DR

El RPO se cumple ≥ el 99% del tiempo (registro de registros/incrementos dentro del objetivo).
RTO black-start (escenario completo) ≤ objetivo (por ejemplo, 4 horas) en pruebas trimestrales.
Éxito de los ejercicios de RD: 100% de las tareas críticas realizadas en la ventana.
Inmutabilidad: proporción de backups con Retention/Lock = 100%.
Comprobaciones de integridad: 100% según lo programado; fallo del portador → ticket en la migración.

Pruebas y ejercicios

Table-top: scripts, roles, listas de cheques, lista de contactos.
Técnico: recuperación selectiva de DB/archivos/secretos en «sandbox» con verificación de cantidades de control y consistencia.
Black-start-drill: Una vez/trimestre (o una vez/seis meses) es el inicio completo del kernel en el sitio DR.
Post-mortem: hechos, cuellos de botella, plan de mejora (SLO/procesos/automatización).

Automatización y artefactos

IaC: clústeres, redes, pilas - en código; DR-ramificaciones/parámetros.
Runbooks: por componentes (Vault/KMS, etcd, DB, pasarelas, frentes).
Paquete DR: copia fuera de línea de los muelles clave (contactos, esquemas, contraseñas de frases seguras), instrucciones de acceso físico.
Canary-restore: un pequeño restore diario y checksum de conciliación.
Etiquetas/etiquetas: «DR-critical», «Warm-only», «Cold-only» para servicios/volúmenes.

Lista de comprobación de implementación

• Las clases de datos y sus RPO/RTO están alineadas con el negocio; se han definido las prioridades de recuperación.
• Implementado cold-backups: medios, inmutabilidad (WORM/Object Lock), offsite/air-gap.
• Catálogos: activos, backups, llaves; sumas de cheque y control de versiones.
• Procedimientos de inicio negro: redes/DNS, IdP/Vault/KMS, plano de control, datos, capa de aplicación.
• Enseñanzas: table-top trimestral; restore canario diario; black-start una vez/trimestre-seis meses.
• Patrones de comunicación y regulación; canales de comunicación separados.
• SLO/métricas/alertas para DR; informes a la administración.
• Acuerdos con proveedores (cintas/archiving-class/DNS/CDN), SLA confirmados.
• Finanzas: presupuesto de medios/archivo, logística, sustitución de medios por plazos.

Errores

«Hay una réplica - no se necesita un respaldo» → el error lógico/cifrador se irá por todas partes.
No hay inmutabilidad/air-gap → un único vector de comprometer todas las copias.
La falta de catálogos/sumas de cheques → ha recuperado «algo», pero no así.
TTL DNS es demasiado grande → una migración de tráfico de varios días.
Claves/KMS en el mismo dominio/cuenta → bloqueo de acceso en caso de incidente.
Los ejercicios «en papel» → RTO/RPO no están confirmados.

Características específicas para iGaming/Fintech

Monedero/núcleo de pago: RPO estricto (≤ 1-5 min) y RTO (≤ 15-60 min); registros en un objeto con WORM; Función de DR «read-only balance» para una comunicación transparente.
PSP/proveedores de contenido: DR-IP/dominio preconcebido, whitelists, certificados, llaves HMAC/mTLS - copias en el paquete DR.
Informes/reguladores: plantillas de notificación, archivos inmutables, integridad probada, registro de actividades.
Picos y eventos: se comprueba la disponibilidad de DR antes de torneos/promociones importantes; restore canario y calentamiento CDN.

Plantillas de minirrunbook

1. Inicialización del clúster DR, carga de claves unseal (dual-control).

2. Restore storage-back (cold-copy).

3. Validación de políticas, emisión de secretos bootstrap para CI/CD/K8s.

1. Desplegar una instancia vacía, restaurar full de cold.

2. Suba los registros WAL (incrementos) hasta el punto de destino.

3. Compruebe la consistencia, habilite la replicación, abra read-only y, a continuación, lea-write.

1. Reducir el TTL en 24-72 h a los riesgos planificados (o mantener bajo constantemente).

2. Conmutación A/AAAA/CNAME por lista de verificación, monitoreo de error/latencia.

3. Aumento gradual del tráfico (canario 5% → 25% → 100%).

Resultado

Un DR confiable basado en backups de cold son: copias aisladas inmutables, procedimientos formalizados de inicio negro, RPO/RTO claros, ejercicios regulares, estrategia de red/DNS pensada y disciplina de claves. Fije todo en IaC y runbook-ah, automatice las comprobaciones de integridad y restore canario - y siempre tendrá una ruta de recuperación controlada incluso después del peor escenario.