Este capítulo forma parte de la Guía de Arquitectura de Datos publicada en Dataprix.com. Corresponde a la Parte II — Bases y plataformas de datos y aborda una de las disciplinas más críticas y, paradójicamente, más descuidadas de la ingeniería de datos: cómo garantizar que la plataforma sobreviva a lo peor y se recupere dentro de los márgenes que el negocio puede tolerar.
Resumen ejecutivo
Existe una verdad incómoda que todo CIO descubre en el peor momento posible: la resiliencia de una plataforma de datos no se mide cuando todo funciona, sino cuando todo deja de funcionar. Un fallo de disco, una corrupción de índices, un despliegue defectuoso que borra una tabla de producción, un ransomware que cifra los volúmenes de almacenamiento a las tres de la madrugada de un viernes. Esos son los escenarios reales que separan a las organizaciones que han invertido en recuperación ante desastres (DR) de las que improvisan bajo presión.
Este capítulo ofrece una hoja de ruta completa para diseñar, implementar y verificar la estrategia de resiliencia y disaster recovery de la capa de datos. No se trata solo de tener backups —que, por supuesto, son imprescindibles— sino de construir un sistema en el que cada componente conoce su RTO (Recovery Time Objective) y su RPO (Recovery Point Objective), donde los procedimientos de recuperación están documentados en runbooks operativos verificados, y donde las pruebas de DR se ejecutan con la misma disciplina con la que se ejecutan las pruebas de rendimiento o los pen tests de seguridad.
Las cifras hablan por sí solas: según datos de Gartner, el coste medio del downtime en grandes empresas supera los 5.600 dólares por minuto. Para una plataforma de datos que alimenta dashboards ejecutivos, pipelines de ML en producción y sistemas transaccionales, cada minuto de indisponibilidad es un minuto de decisiones empresariales tomadas a ciegas. Y lo que es peor: la pérdida de datos —cuando el RPO no está diseñado correctamente— puede significar horas, días o incluso semanas de información irrecuperable.
A lo largo de las próximas secciones recorreremos los fundamentos de RTO y RPO, los patrones arquitectónicos de resiliencia, la construcción de runbooks efectivos, las estrategias de backup y replicación, las pruebas de DR como disciplina ingenieril, y los errores más frecuentes que suelen encontrarse en consultorías con empresas de todos los sectores. El objetivo es que, al terminar de leer, tu organización pueda responder con seguridad a una pregunta simple: si mañana se pierde la región principal de nuestro cloud, ¿sabemos exactamente qué hacer, cuánto tardaremos y cuántos datos perderemos?
RTO y RPO: las dos métricas que definen la tolerancia del negocio
Antes de hablar de tecnología, herramientas o proveedores cloud, hay que hablar de negocio. RTO y RPO no son métricas técnicas: son compromisos empresariales que la capa de datos debe cumplir. Definirlos correctamente requiere una conversación entre el equipo de ingeniería, los responsables de negocio y la dirección, porque en última instancia determinan cuánto dinero está dispuesta la organización a invertir en resiliencia.
El Recovery Time Objective (RTO) responde a la pregunta: ¿cuánto tiempo puede la organización operar sin acceso a esta plataforma de datos antes de que el impacto sea inaceptable? No es lo mismo un data warehouse analítico cuyo RTO razonable puede ser de cuatro horas —porque los informes pueden esperar a la mañana siguiente— que la base de datos transaccional de un sistema de pagos cuyo RTO debería medirse en segundos o, como máximo, en minutos. Cada sistema, cada dataset, cada pipeline tiene un RTO diferente, y uno de los errores más frecuentes es aplicar la misma política de recuperación a toda la plataforma sin discriminar por criticidad.
El Recovery Point Objective (RPO), por su parte, responde a una pregunta diferente pero igualmente vital: ¿cuántos datos podemos permitirnos perder? Un RPO de cero significa que no puede perderse ni una sola transacción: cada escritura debe estar replicada de forma síncrona antes de ser confirmada. Un RPO de una hora implica que, en el peor escenario, podríamos perder hasta sesenta minutos de datos. Para un pipeline de ingesta batch que carga datos una vez al día, un RPO de veinticuatro horas podría ser perfectamente aceptable. Para la tabla de pedidos en tiempo real de un e-commerce durante el Black Friday, un RPO de más de treinta segundos es un riesgo empresarial difícil de justificar.
La matriz RTO/RPO como herramienta de priorización
En la práctica, lo que recomendamos es construir una matriz de clasificación de activos de datos que cruce el nivel de criticidad del sistema con sus requisitos de RTO y RPO. Esta matriz se convierte en el documento rector de toda la estrategia de DR, porque permite asignar inversiones de forma proporcional al riesgo. Un enfoque habitual distingue entre cuatro niveles de servicio, que en consultoría suelen denominarse tiers de resiliencia.
El Tier 1 — Misión crítica agrupa aquellos sistemas cuya indisponibilidad detiene la actividad principal del negocio: sistemas de pagos, bases de datos transaccionales de core bancario, plataformas de trading, sistemas de control industrial. En este tier, el RTO típico se sitúa por debajo de los quince minutos y el RPO tiende a cero. Aquí es donde se justifican las arquitecturas active-active con replicación síncrona multi-región, los mecanismos de failover automático y la inversión en infraestructura redundante que puede duplicar o triplicar el coste operativo.
El Tier 2 — Crítico para negocio incluye sistemas cuya pérdida temporal es dolorosa pero no paralizante: el data warehouse que alimenta los informes de dirección, los dashboards de operaciones, los feature stores de modelos ML en producción. Un RTO de entre quince minutos y una hora, con un RPO de entre cinco y treinta minutos, suele ser el punto de equilibrio. Las arquitecturas active-standby con replicación asíncrona y failover semi-automático son la opción más habitual.
El Tier 3 — Operativo abarca entornos de desarrollo, staging, data lakes de exploración, datasets históricos que se consultan de forma ocasional. Su RTO puede oscilar entre una y cuatro horas, con un RPO de una a veinticuatro horas. Los snapshots periódicos y los backups regulares, combinados con runbooks de restauración bien documentados, suelen ser suficientes.
Finalmente, el Tier 4 — Archivado corresponde a datos que deben conservarse por requisitos regulatorios o legales pero cuyo acceso es infrecuente: logs históricos, datasets de auditoría, backups de largo plazo. Aquí el RTO puede medirse en días y el RPO coincide con la última copia de seguridad completa. Soluciones de almacenamiento frío como S3 Glacier, Azure Archive Storage o Google Coldline son las opciones naturales.
Lo importante de esta clasificación no es el nombre que reciba cada tier, sino el ejercicio de sentarse con los responsables de negocio y llegar a un acuerdo cuantificado. Se ha dado el caso de organizaciones donde el CTO asumía que el data warehouse era Tier 1 mientras el CFO consideraba que podía estar caído un día entero sin impacto relevante. Esa desconexión es peligrosa, porque lleva a sobreinvertir en unos sitios e infrainvertir en otros.
Patrones arquitectónicos de resiliencia para plataformas de datos
Una vez definidos los tiers de servicio, toca traducir esos compromisos empresariales en decisiones arquitectónicas concretas. Y aquí es donde la ingeniería de datos se cruza con la ingeniería de infraestructura, porque la resiliencia no se añade después como una capa de barniz: se diseña desde el primer día o se paga diez veces más caro cuando hay que retrofitearla.
Active-Active: resiliencia máxima, complejidad máxima
El patrón active-active multi-región es el santo grial de la alta disponibilidad. Dos o más instancias de la plataforma de datos operan simultáneamente en regiones geográficas distintas, cada una capaz de asumir el cien por cien de la carga en caso de fallo de la otra. Los datos se replican de forma síncrona —o cuasi-síncrona— entre regiones, y un balanceador global dirige el tráfico según latencia, disponibilidad y políticas de routing.
En el mundo de las bases de datos, este patrón se materializa de formas diferentes según la tecnología. CockroachDB y Google Spanner ofrecen replicación síncrona distribuida a nivel de protocolo, lo que permite lecturas y escrituras consistentes desde cualquier región. Amazon Aurora Global Database ofrece replicación asíncrona con tiempos de lag inferiores al segundo entre regiones, con la posibilidad de promover una réplica secundaria a primaria en menos de un minuto. Azure Cosmos DB, por su parte, permite configurar escrituras multi-región con diferentes niveles de consistencia, desde consistencia eventual hasta strong consistency con penalización de latencia.
El coste del active-active no es trivial. No hablamos solo de duplicar la infraestructura —que ya es significativo—, sino de la complejidad operativa que introduce. Los conflictos de escritura concurrente, las estrategias de resolución de conflictos (last-write-wins, vector clocks, CRDTs), la gestión de esquemas coordinados entre regiones, la monitorización de lag de replicación como métrica crítica... todo esto requiere un equipo de ingeniería experimentado y procesos operativos maduros. En nuestra experiencia, el active-active multi-región solo se justifica para sistemas de Tier 1 donde el coste del downtime supera con creces el coste de la infraestructura redundante.
Active-Standby: el equilibrio más habitual
El patrón active-standby (también denominado active-passive o pilot light) es la opción más común para sistemas de Tier 2 y, en muchos casos, una alternativa pragmática para Tier 1 cuando el presupuesto no alcanza para un active-active completo. En este modelo, existe una instancia primaria que sirve toda la carga de trabajo, y una o varias réplicas secundarias que reciben los datos de forma asíncrona y están listas para asumir el rol de primarias en caso de fallo.
La diferencia clave con el active-active es que las réplicas secundarias no sirven tráfico de escritura en condiciones normales —aunque sí pueden servir lecturas para distribuir la carga—. Cuando la primaria falla, se ejecuta un proceso de failover que puede ser automático (gestionado por el servicio cloud o por un orquestador como Patroni para PostgreSQL) o manual (requiere intervención del equipo de guardia según el runbook).
Un caso de uso habitual lo encontramos en el sector asegurador. Por ejemplo, una compañía de seguros mantenía su base de datos de pólizas en PostgreSQL sobre Amazon RDS Multi-AZ, con una réplica de lectura en otra región. En condiciones normales, la réplica servía los informes de business intelligence, descargando la primaria. Cuando se produjo una avería en la zona de disponibilidad principal —un incidente de conectividad que afectó a una AZ completa de eu-west-1—, el failover automático de RDS Multi-AZ restauró el servicio en menos de dos minutos. La réplica inter-región no llegó a activarse, pero estaba lista como segunda línea de defensa. El RPO medido fue de cero, porque Multi-AZ utiliza replicación síncrona dentro de la misma región.
Warm Standby y Cold Standby: resiliencia económica
Para sistemas de Tier 3 y Tier 4, mantener una réplica activa permanente es un lujo innecesario. Aquí entran los patrones de warm standby y cold standby. En el warm standby, la infraestructura de DR existe pero opera a capacidad reducida: instancias más pequeñas, réplicas con menor frecuencia de actualización, clusters con menos nodos. Cuando se activa, se escala para absorber la carga completa. En el cold standby, la infraestructura no existe hasta que se necesita: se parte de backups almacenados en otro lugar (otra región, otro cloud, almacenamiento offline) y se reconstruye el entorno desde cero.
El warm standby es la opción natural para data warehouses que no son de misión crítica. Un cluster de Snowflake o BigQuery en una región secundaria, alimentado con una réplica retrasada del dataset, puede escalarse en minutos para asumir la carga analítica. El cold standby, por su parte, se reserva para entornos de desarrollo, datasets históricos o sistemas cuya reconstrucción puede esperar horas o días.
La trampa del cold standby es que, si nunca se prueba, es más un deseo que un plan. Hemos visto organizaciones que descubren, en plena crisis, que los backups que almacenaban en S3 Glacier Deep Archive tardan doce horas en restaurarse, o que el script de Terraform que supuestamente reconstruía el entorno no se ha actualizado en dieciocho meses y falla por incompatibilidad de versiones. Un plan de DR que no se prueba no es un plan: es una esperanza.
Estrategias de backup y replicación: más allá de la copia de seguridad
Los backups son el fundamento de cualquier estrategia de DR, pero también son el componente que más frecuentemente falla cuando más se necesita. No porque la tecnología sea deficiente, sino porque la operativa alrededor de los backups suele degradarse con el tiempo: los scripts dejan de monitorizarse, los tamaños crecen hasta superar las ventanas de backup, las restauraciones nunca se prueban y la retención se acumula sin política clara.
Tipos de backup y su impacto en RPO
El backup completo (full backup) captura el estado íntegro de la base de datos en un momento dado. Es el más simple de restaurar pero el más costoso en tiempo y almacenamiento. Para una base de datos de producción de varios terabytes, un full backup puede tardar horas y consumir un ancho de banda considerable si se transfiere a otra región o a almacenamiento externo.
El backup incremental captura únicamente los cambios producidos desde el último backup (ya sea completo o incremental). Reduce drásticamente el tiempo y el espacio requeridos para cada operación, pero complica la restauración: para volver a un estado consistente, necesitas la cadena completa desde el último full backup más todos los incrementales posteriores. Si un solo eslabón de la cadena se corrompe, toda la restauración falla.
El backup diferencial captura los cambios desde el último full backup, independientemente de los diferenciales previos. Es un compromiso entre el full y el incremental: más grande que el incremental, pero más robusto en restauración porque solo necesitas el último full más el último diferencial.
En la práctica, la estrategia más habitual combina los tres tipos en lo que se conoce como política 3-2-1: tres copias de los datos, en dos tipos de medio diferente, con una copia fuera de sitio (offsite). Para plataformas de datos modernas en cloud, esta regla se traduce en: snapshots automáticos dentro de la misma región, réplicas asíncronas en otra región, y backups periódicos a un proveedor o bucket diferente (cross-account, cross-cloud o incluso cinta virtual).
Replicación síncrona vs asíncrona: el dilema latencia-consistencia
La replicación síncrona garantiza que cada escritura se confirma únicamente cuando todas las réplicas la han registrado. Esto proporciona un RPO de cero: no se pierde ni una transacción. Pero el precio es latencia adicional en cada operación de escritura, porque el sistema debe esperar la confirmación de la réplica más lenta. Dentro de la misma región cloud (entre zonas de disponibilidad), esta latencia suele ser de uno a tres milisegundos, lo cual es aceptable para la mayoría de cargas de trabajo. Entre regiones separadas por miles de kilómetros, la latencia puede superar los cien milisegundos, lo que la hace inviable para sistemas transaccionales de alta frecuencia.
La replicación asíncrona desacopla la escritura de la confirmación de la réplica. La primaria confirma la operación inmediatamente y envía los cambios a la réplica en segundo plano. Esto elimina el impacto en latencia pero introduce un replication lag: un intervalo de tiempo durante el cual la réplica está "detrás" de la primaria. Si la primaria falla durante ese intervalo, las transacciones en tránsito se pierden. El RPO en replicación asíncrona no es cero, sino que depende del lag medio, que puede ir desde milisegundos (en condiciones normales dentro de la misma región) hasta minutos o incluso horas (bajo carga extrema o con conectividad degradada entre regiones).
Un caso sectorial que ilustra perfectamente este dilema lo encontramos en banca transaccional. Un banco europeo operaba su core de transferencias SEPA sobre un cluster de Oracle Data Guard con replicación síncrona entre dos data centers separados veinte kilómetros. La latencia adicional de tres milisegundos por transacción era aceptable. Cuando el regulador exigió una tercera copia en otra jurisdicción (cumplimiento de DORA), la distancia al tercer sitio —más de mil kilómetros— hacía inviable la replicación síncrona. La solución fue una arquitectura híbrida: síncrona entre los dos sitios cercanos (RPO cero para fallos locales) y asíncrona hacia el tercer sitio (RPO de dos a cinco segundos para escenarios de desastre regional). El banco documentó este RPO como riesgo residual aceptado por el comité de riesgos, con mitigación adicional mediante logs de transacciones que podían reenviarse manualmente desde los sistemas front-end.
El problema de los backups que nadie restaura
Hay una ley no escrita en la ingeniería de datos que dice que un backup que no se ha restaurado con éxito no es un backup: es un acto de fe. Las causas de fallos silenciosos en backups son numerosas y a veces embarazosamente simples: permisos incorrectos que impiden el acceso al bucket de destino, snapshots que capturan un estado inconsistente porque la base de datos estaba en medio de un checkpoint, backups cifrados cuya clave de descifrado se ha rotado y ya no está disponible, backups que se completan correctamente pero que la herramienta de restauración no soporta porque ha cambiado de versión.
Un caso especialmente doloroso se dio en una empresa del sector logístico que realizaba backups diarios de su base de datos MySQL de tracking de envíos. Durante dieciocho meses, los backups se completaban sin error aparente. Cuando un fallo de hardware destruyó el disco primario y la réplica local simultáneamente —ambos estaban en la misma cabina de almacenamiento, un error de diseño que nadie había revisado—, el equipo descubrió que los backups lógicos (mysqldump) habían estado capturando tablas de forma no atómica, generando inconsistencias entre tablas con claves foráneas. La restauración requirió una intervención manual de tres días para reconciliar las relaciones entre tablas, durante los cuales el sistema de tracking estuvo operando con datos parciales. Fue un punto de inflexión: a partir de ese incidente, implementaron backups físicos con Percona XtraBackup, verificación automática de restauración en un entorno de staging cada semana, y separación física de la réplica respecto a la primaria.
Runbooks de DR: el arte de convertir el caos en procedimiento
Si la estrategia de resiliencia es el "qué" y la arquitectura es el "cómo", los runbooks son el "quién hace qué, en qué orden, con qué herramientas y en cuánto tiempo" cuando se activa un escenario de desastre. Un runbook no es un documento genérico de buenas prácticas: es un procedimiento operativo paso a paso, diseñado para ser ejecutado bajo presión por personas que pueden estar somnolientas, estresadas o poco familiarizadas con el sistema específico que ha fallado.
La diferencia entre un buen runbook y un mal runbook es la diferencia entre un equipo que recupera la plataforma en treinta minutos y un equipo que pasa tres horas discutiendo qué hacer mientras el CEO llama cada quince minutos pidiendo un ETA.
Anatomía de un runbook de DR efectivo
Un runbook operativo de calidad industrial contiene, como mínimo, los siguientes elementos. El primero es una descripción del escenario que activa el procedimiento. No puede ser algo genérico como "la base de datos no está disponible". Debe ser específico: "la instancia primaria de PostgreSQL en la región eu-west-1 no responde a health checks durante más de cinco minutos y la causa raíz no se ha identificado en los primeros diez minutos de triaje". La especificidad es crucial porque determina cuándo se escala a DR en lugar de intentar una reparación in situ.
El segundo elemento es la matriz de notificación y escalado. Quién recibe la alerta inicial (normalmente el ingeniero de guardia), a quién se escala si no responde en X minutos, a partir de qué momento se informa a dirección y a comunicación. Los números de teléfono, los canales de Slack, los grupos de PagerDuty: todo debe estar en el runbook, no en la cabeza de alguien ni en un wiki que puede estar en la misma región que está caída.
El tercero —y el más importante— son los pasos de recuperación. Cada paso debe ser una instrucción ejecutable, con el comando concreto que hay que ejecutar, la URL de consola que hay que abrir, o la acción que hay que realizar en la interfaz del proveedor cloud. Un paso como "activar el failover de la base de datos" no es suficiente. Lo que necesitas es algo como: "Acceder a la consola de AWS RDS en la región eu-west-1. Seleccionar la instancia rds-prod-primary. En Actions, hacer clic en Failover. Confirmar la acción. Verificar en CloudWatch que la métrica FreeableMemory de la nueva primaria está por encima de 2 GB antes de redirigir tráfico". Ese nivel de detalle es el que marca la diferencia cuando la persona que ejecuta el runbook no es la misma que lo escribió.
El cuarto elemento son los puntos de verificación. Después de cada paso crítico, el runbook debe incluir una comprobación que confirme que el paso se ha completado correctamente antes de avanzar al siguiente. "Verificar que SELECT 1 devuelve resultado en la nueva primaria" o "Confirmar que el endpoint DNS se resuelve a la IP de la instancia de DR" son ejemplos de verificaciones que evitan avanzar sobre un estado inconsistente.
El quinto elemento son las decisiones de rollback. ¿Qué pasa si el failover falla? ¿Si la instancia de DR no puede asumir la carga? ¿Si los datos están más desactualizados de lo esperado? El runbook debe contemplar estos fork points con instrucciones claras para cada camino.
Y el sexto, a menudo olvidado, son los pasos de post-recuperación: cómo volver al estado nominal una vez resuelta la crisis. Esto incluye la reconexión de réplicas, la verificación de integridad de datos, la reconstrucción de la infraestructura fallida, la generación del post-mortem y la actualización del propio runbook con las lecciones aprendidas.
Runbooks como código: la evolución necesaria
La tendencia más relevante en la gestión de runbooks es tratarlos como código versionado en lugar de documentos estáticos en una wiki. Herramientas como Rundeck, PagerDuty Runbook Automation, Shoreline.io o incluso scripts en repositorios Git permiten que los runbooks sean ejecutables, versionados, revisados por pares y probados automáticamente.
En el sector fintech, hay equipos que implementan sus runbooks como Jupyter notebooks que combinan documentación en Markdown con celdas ejecutables que realizan las verificaciones y acciones de recuperación. El ingeniero de guardia abre el notebook, lee las instrucciones y ejecuta las celdas secuencialmente, verificando los resultados en cada paso. Si algo falla, el output queda registrado en el propio notebook, lo que facilita el post-mortem. Otros equipos más maduros codifican los runbooks como pipelines de Terraform o Ansible que pueden ejecutarse con un solo comando, reduciendo el margen de error humano al mínimo.
El riesgo de la automatización total, sin embargo, no es despreciable. Un runbook automático que se ejecuta sin supervisión puede amplificar un fallo en lugar de resolverlo. El ejemplo clásico es un failover automático que se dispara por un falso positivo del health check —un pico temporal de latencia que supera el umbral configurado— y provoca un split-brain donde ambas instancias se creen primarias. Por eso, la práctica recomendada es automatizar las verificaciones y preparar las acciones, pero requerir confirmación humana para los pasos irreversibles como la promoción de una réplica o el cambio de DNS.
Pruebas de DR: la disciplina que separa la teoría de la realidad
Si hay un mensaje que queremos que quede grabado a fuego después de este capítulo es este: una estrategia de DR que no se prueba regularmente no existe. Las pruebas de DR son el equivalente a los simulacros de incendio: nadie quiere hacerlos, todos los ven como una pérdida de tiempo hasta que llega el día en que el edificio arde de verdad y la diferencia entre un simulacro mensual y ninguno se mide en vidas. En nuestro caso, en datos.
Tipos de pruebas de DR
Las pruebas de mesa (tabletop exercises) son el nivel más básico y el punto de partida ideal para organizaciones que nunca han probado su plan de DR. Consisten en reunir al equipo alrededor de una mesa —o una videollamada— y recorrer un escenario de desastre paso a paso, sin tocar la infraestructura real. El facilitador describe el escenario ("la región principal de AWS está indisponible desde hace treinta minutos y el health check de la base de datos primaria devuelve timeout"), y el equipo describe qué haría, en qué orden, quién se responsabiliza de cada acción. El valor de este ejercicio no es técnico sino organizativo: descubre gaps de comunicación, ambigüedades en los runbooks, suposiciones no verificadas y dependencias circulares. Habitualmente, el primer tabletop exercise de una organización siempre descubre al menos tres o cuatro problemas graves que nadie había anticipado.
Las pruebas funcionales en entorno aislado van un paso más allá. Se replica el entorno de producción (o una versión reducida) en un entorno separado, se inyecta el fallo simulado y se ejecuta el runbook completo. El objetivo es verificar que los procedimientos técnicos funcionan: que los backups se restauran correctamente, que el failover completa en el tiempo esperado, que las aplicaciones se reconectan sin intervención manual, que los datos son consistentes después de la recuperación. Estas pruebas requieren más preparación pero son esenciales para validar el RTO y RPO declarados.
Las pruebas en producción (gamedays) son el nivel máximo de rigor. Consisten en provocar un fallo real en producción y verificar que el sistema se recupera automáticamente o que el equipo ejecuta el runbook con éxito. Netflix popularizó este enfoque con su Chaos Monkey, y desde entonces herramientas como Gremlin, Litmus, AWS Fault Injection Simulator (FIS) y Azure Chaos Studio han democratizado la ingeniería del caos. Un gameday típico en una plataforma de datos podría consistir en terminar la instancia primaria de la base de datos durante horario de oficina y medir cuánto tiempo tarda el sistema en recuperarse.
Es importante subrayar que los gamedays en producción requieren madurez operativa. No es algo que se haga el primer día: es el final de un proceso que empieza con tabletop exercises, pasa por pruebas funcionales, y llega a producción cuando el equipo tiene confianza en sus mecanismos de recuperación. Ejecutar un gameday prematuramente puede causar el mismo desastre que se pretende prevenir.
Frecuencia y planificación de pruebas
La frecuencia de las pruebas depende del tier de resiliencia del sistema. Para sistemas Tier 1, las pruebas funcionales deberían ser mensuales y los gamedays trimestrales. Para Tier 2, pruebas funcionales trimestrales y al menos un gameday anual. Para Tier 3, una prueba funcional semestral suele ser suficiente, siempre que los backups se verifiquen automáticamente con mayor frecuencia.
Cada prueba debe generar un informe de resultados que documente: el escenario probado, el RTO y RPO medidos vs los declarados, los problemas encontrados, las acciones correctivas y la fecha comprometida para implementarlas. Este informe se convierte en evidencia de auditoría para frameworks regulatorios como DORA (Digital Operational Resilience Act) en el sector financiero europeo, SOC 2 para empresas SaaS, o ISO 22301 como estándar internacional de continuidad de negocio.
Chaos engineering aplicado a la capa de datos
La ingeniería del caos aplicada específicamente a plataformas de datos tiene matices propios que la distinguen de la inyección de fallos en servicios stateless. Cuando inyectas un fallo en un microservicio sin estado, lo peor que puede pasar es que se pierdan algunas peticiones en vuelo. Cuando inyectas un fallo en una base de datos, puedes perder datos, corromper índices, dejar transacciones a medias o provocar un split-brain. Por eso, los experimentos de caos en la capa de datos deben diseñarse con especial cuidado.
Los escenarios habituales incluyen: terminación de la instancia primaria para verificar el failover automático, inyección de latencia en la replicación para verificar el comportamiento de las aplicaciones cuando la réplica se retrasa, llenado del disco para comprobar que las alertas se disparan y que la base de datos gestiona la situación sin corrupción, corrupción selectiva de bloques (en entorno controlado) para verificar que los checksums detectan el problema, y revocación de credenciales para simular un incidente de seguridad que corta el acceso a los datos.
Un caso especialmente instructivo lo proporcionó una empresa de e-commerce durante su preparación para el Black Friday. El equipo realizó un gameday que consistía en desconectar la réplica de lectura de su cluster de Amazon Aurora durante un periodo de carga simulada. Descubrieron que la aplicación no gestionaba correctamente la pérdida de la réplica: en lugar de redirigir las lecturas a la primaria, lanzaba excepciones que cascadeaban hasta provocar errores visibles para el usuario. El fix —un retry con fallback al endpoint primario— se implementó en dos días. Sin el gameday, ese bug habría aparecido por primera vez con millones de usuarios activos.
Los diez errores de DR que más veces se repiten
Tras las auditorías de resiliencia en organizaciones de todos los tamaños y sectores, hay un catálogo de errores que se repite con una regularidad casi predecible. Compartirlos es, quizá, la forma más directa de aportar valor a quien lee este capítulo.
- El primero y más frecuente es el "backup de Schrödinger": backups que existen y no existen a la vez, porque nadie los ha restaurado nunca. El equipo asume que funcionan porque los scripts no dan error, pero cuando llega el momento de la verdad, la restauración falla por cualquiera de las razones que ya hemos descrito.
- El segundo es la falta de clasificación por tiers. Todas las bases de datos reciben el mismo tratamiento de DR —normalmente insuficiente—, porque nadie ha hecho el ejercicio de priorización con el negocio. Esto lleva a la paradoja de que el entorno de desarrollo tiene la misma política de backup que el core transaccional.
- El tercero es confiar ciegamente en el proveedor cloud. "AWS se encarga de la alta disponibilidad" es una frase que hemos escuchado más veces de las que nos gustaría. Los proveedores cloud ofrecen herramientas excelentes para construir arquitecturas resilientes, pero la responsabilidad de diseñar, configurar y probar la estrategia de DR es del cliente. Multi-AZ no protege contra una corrupción lógica de datos; los snapshots automáticos no sirven si la retención configurada es menor que el tiempo que tardas en detectar un problema.
- El cuarto es tener los runbooks en la misma infraestructura que falla. Si tus runbooks están en una wiki interna alojada en la misma región que tu base de datos, cuando la región caiga, tus runbooks caerán con ella. Parece obvio, pero ocurre con una frecuencia sorprendente.
- El quinto es no contemplar los desastres lógicos además de los físicos. Un DELETE sin WHERE ejecutado por error, un despliegue que corrompe una tabla de metadatos, un ransomware que cifra los volúmenes: estos escenarios son estadísticamente más probables que la destrucción física de un data center, y requieren
estrategias de recuperación diferentes (point-in-time recovery, versionado de datos, inmutabilidad de backups).
- El sexto es no considerar las dependencias externas en el plan de DR. Tu base de datos puede recuperarse en cinco minutos, pero si el DNS tarda treinta en propagarse, si el servicio de autenticación no está en DR, o si el pipeline de ingesta no sabe reconectarse a la nueva primaria, el RTO real será mucho mayor que el que mide tu prueba aislada.
- El séptimo es la ausencia de inmutabilidad en los backups. Un ransomware sofisticado no solo cifra los datos de producción: busca y destruye los backups. Si los backups están en el mismo account cloud, con los mismos permisos, son igual de vulnerables. Las mejores prácticas actuales exigen backups en un account separado con MFA delete activado, Object Lock habilitado y políticas de retención inmutables que ni siquiera un administrador pueda borrar.
- El octavo es subestimar el tiempo de decisión humana en el RTO. Las pruebas de DR suelen medir el tiempo técnico de recuperación, pero en un incidente real hay un intervalo —a veces largo— entre que se detecta el problema, se confirma que es un desastre real y no un falso positivo, se convoca al equipo adecuado, se decide activar el plan de DR y alguien empieza a ejecutar el runbook. Ese intervalo puede sumar treinta minutos, una hora o más, y debe incluirse en el cálculo del RTO real.
- El noveno es la degradación del plan con el tiempo. El plan de DR que se diseñó y probó hace dos años puede ser obsoleto hoy: nuevas bases de datos, cambios de región, migraciones de servicio, rotaciones de personal que se llevan el conocimiento tácito. Sin un proceso de revisión y actualización periódica del plan —idealmente ligado a cada cambio significativo en la infraestructura—, el plan se degrada silenciosamente.
- Y el décimo, quizá el más difícil de resolver, es la falta de cultura de resiliencia. En muchas organizaciones, invertir en DR se percibe como un coste sin retorno visible, porque el éxito de un buen plan de DR es que nunca tengas que usarlo. Convencer al comité de dirección de que destine presupuesto y tiempo de ingeniería a algo que solo demuestra su valor en un escenario que todos esperan que no ocurra es un ejercicio de comunicación que requiere datos, ejemplos sectoriales y, a veces, el empujón de un regulador o un incidente ajeno que sacuda la complacencia.
DR en entornos cloud y multicloud: particularidades y herramientas
Los proveedores cloud han invertido enormemente en facilitar las estrategias de DR, pero cada uno lo hace con herramientas y paradigmas diferentes, lo que añade complejidad en entornos multicloud o híbridos.
En Amazon Web Services, la columna vertebral de DR para bases de datos es la combinación de RDS Multi-AZ (failover automático dentro de una región), Cross-Region Read Replicas (réplicas asíncronas en otra región), AWS Backup (gestión centralizada de snapshots y backups con políticas de retención y cross-account copy), y AWS Elastic Disaster Recovery (DRS) para replicación continua de servidores completos. Para data lakes en S3, las herramientas clave son S3 Cross-Region Replication, S3 Object Lock para inmutabilidad, y S3 Versioning para protección contra borrados accidentales.
En Microsoft Azure, la estrategia se articula en torno a Azure SQL Geo-Replication y Auto-failover Groups para bases de datos SQL, Cosmos DB Multi-Region Writes para cargas distribuidas globalmente, Azure Site Recovery (ASR) como orquestador general de DR, y Azure Backup con Immutable Vaults para protección contra ransomware.
En Google Cloud, las piezas fundamentales son Cloud SQL High Availability con failover automático, Cloud Spanner con replicación multi-región nativa, Backup and DR Service para gestión centralizada, y GCS Dual-Region Buckets para almacenamiento resiliente.
Para organizaciones que operan en multicloud —ya sea por estrategia deliberada, por adquisiciones o por requisitos regulatorios—, la complejidad de DR se multiplica. No existe una herramienta nativa que replique datos entre AWS y Azure, o entre GCP y AWS, de forma transparente. Las alternativas pasan por herramientas de terceros como Zerto, Commvault, Veeam o soluciones basadas en replicación a nivel de aplicación (la propia base de datos replica hacia su equivalente en otro cloud). En estos escenarios, la estandarización de los runbooks y la automatización vía Terraform o Pulumi se vuelven aún más críticas, porque la recuperación puede implicar reconstruir la infraestructura en un cloud diferente.
DR y cumplimiento normativo: lo que exigen los reguladores
La recuperación ante desastres ha dejado de ser una buena práctica opcional para convertirse en un requisito regulatorio explícito en muchos sectores. Conocer las obligaciones normativas es fundamental para dimensionar correctamente la inversión en DR y para evitar sanciones que pueden ser considerablemente más costosas que la propia infraestructura de resiliencia.
El Digital Operational Resilience Act (DORA), aplicable desde enero de 2025 a todas las entidades financieras en la Unión Europea, establece requisitos detallados de continuidad de negocio y recuperación ante desastres para los sistemas de TI. Exige que las entidades identifiquen y clasifiquen sus funciones críticas, definan RTO y RPO para cada una, implementen mecanismos de recuperación, y realicen pruebas periódicas documentadas. Lo más significativo de DORA es que las pruebas de resiliencia digital deben incluir threat-led penetration testing (TLPT) para las entidades más significativas, y los resultados deben reportarse al regulador.
La directiva NIS2, también de aplicación en la UE, amplía las obligaciones de ciberseguridad y resiliencia operativa a un espectro mucho más amplio de sectores: energía, transporte, salud, infraestructura digital, manufactura de productos críticos, servicios postales, gestión de residuos y alimentación. Las organizaciones afectadas deben implementar medidas de gestión de riesgos que incluyan la continuidad de negocio y la gestión de crisis.
En el sector sanitario, normativas como HIPAA en Estados Unidos exigen la existencia de planes de contingencia que garanticen el acceso a la información de salud protegida (PHI) durante emergencias, así como la implementación de procedimientos de restauración de datos en un plazo razonable.
La norma ISO 22301 de gestión de continuidad de negocio, aunque no es obligatoria, se ha convertido en el estándar de facto para certificar la madurez de los planes de DR. Muchas organizaciones la utilizan como marco de referencia y como sello de confianza frente a clientes y socios.
Caso práctico: diseñando la estrategia de DR para una healthtech con datos sensibles
Para aterrizar todo lo expuesto, veamos un caso que sintetiza muchos de los desafíos descritos. Se trata de una empresa healthtech europea que opera una plataforma de historiales clínicos electrónicos (EHR) para una red de clínicas privadas en tres países. La plataforma gestiona datos sensibles de pacientes (categoría especial bajo GDPR), procesa citas, resultados de laboratorio y prescripciones, y alimenta un módulo analítico para la gestión hospitalaria.
El primer paso fue realizar la clasificación por tiers. La base de datos transaccional de historiales clínicos se clasificó como Tier 1: si un médico no puede acceder al historial de un paciente durante una consulta, el impacto es inmediato y potencialmente peligroso. El módulo analítico se clasificó como Tier 2: importante para la gestión pero no para la atención inmediata. El data lake de investigación clínica, como Tier 3.
Para el Tier 1, se diseñó una arquitectura active-standby con PostgreSQL en Amazon RDS Multi-AZ como primaria en eu-west-1 (Irlanda), con una réplica de lectura inter-región en eu-central-1 (Fráncfort). La replicación dentro de la región es síncrona (RDS Multi-AZ), y la inter-región es asíncrona con un lag monitorizado que normalmente no supera los quinientos milisegundos. El RTO declarado es de quince minutos y el RPO de treinta segundos. Se implementó un failover semi-automático: un script en AWS Lambda monitoriza la salud de la primaria y, si detecta indisponibilidad durante más de cinco minutos, notifica al equipo de guardia con un botón de confirmación para iniciar la promoción de la réplica de DR. La decisión de no automatizar completamente el failover inter-región fue deliberada: en el contexto sanitario, una promoción errónea que cause un split-brain con datos de pacientes divergentes es un escenario más peligroso que un RTO ligeramente más largo.
Para el Tier 2, el módulo analítico sobre Snowflake se configuró con replicación de bases de datos entre la cuenta principal en AWS eu-west-1 y una cuenta secundaria en eu-central-1. La réplica se actualiza cada quince minutos. En caso de indisponibilidad de la región principal, el equipo puede redirigir los dashboards de BI a la cuenta secundaria en aproximadamente una hora —el tiempo necesario para verificar la consistencia y actualizar los endpoints—.
Para el Tier 3, el data lake de investigación en S3 se protege con Cross-Region Replication y backups semanales completos a un bucket en una cuenta AWS separada con Object Lock habilitado. El RTO declarado es de veinticuatro horas.
Los runbooks se codificaron como scripts de Ansible almacenados en un repositorio Git privado con copia en un segundo proveedor (GitHub y GitLab, para evitar depender de uno solo). Cada runbook incluye los pasos de recuperación, los puntos de verificación, las decisiones de escalado y los pasos de post-recuperación. Se redactaron en inglés para garantizar la comprensión por parte de todo el equipo distribuido.
Las pruebas de DR se planificaron según la frecuencia recomendada por tier. Para Tier 1, se realiza un tabletop exercise mensual y un failover funcional completo a la región de DR cada trimestre. La primera prueba funcional reveló que el script de promoción de la réplica tenía un error en la gestión de la conexión SSL, que habría bloqueado las aplicaciones durante varios minutos adicionales. Para Tier 2, se realiza una prueba funcional semestral. Para Tier 3, se verifica la restauración de backups trimestralmente.
El coste adicional de toda la estrategia de DR se cuantificó en un incremento del 40 % sobre el coste base de la infraestructura de datos. El CFO inicialmente cuestionó la cifra, pero el DPO (Data Protection Officer) y el CISO presentaron el análisis de riesgo: una brecha de datos sanitarios bajo GDPR puede acarrear multas de hasta el 4 % de la facturación global, más los daños reputacionales y la potencial responsabilidad civil por perjuicio a pacientes. La inversión en DR se aprobó sin más discusión.
Checklist operativo de resiliencia y DR
Para cerrar el capítulo con una herramienta accionable, ofrecemos este checklist que todo equipo de datos debería revisar periódicamente. No pretende ser exhaustivo, sino servir como punto de partida para una evaluación rápida del estado de madurez de la estrategia de DR.
Clasificación y gobernanza: ¿Todos los activos de datos están clasificados por tiers de criticidad? ¿Los RTO y RPO de cada tier están acordados formalmente con el negocio y documentados? ¿Existe un responsable identificado (owner) para cada tier? ¿Se revisan los tiers al menos anualmente o cuando hay cambios significativos en la plataforma?
Backups: ¿Se realizan backups según la frecuencia que exige el RPO de cada tier? ¿Se verifican automáticamente las restauraciones de backups al menos semanalmente para Tier 1 y mensualmente para Tier 2? ¿Los backups están almacenados en una ubicación independiente (otra región, otro account, otro cloud)? ¿Los backups críticos son inmutables (Object Lock, MFA delete, o equivalente)? ¿La retención configurada es suficiente para detectar y recuperarse de desastres lógicos como corrupción de datos o ransomware?
Replicación y failover: ¿Los sistemas Tier 1 y Tier 2 tienen réplicas de DR en otra zona de disponibilidad o región? ¿El mecanismo de failover está automatizado (o semi-automatizado con confirmación humana) y probado? ¿El lag de replicación se monitoriza con alertas cuando supera el umbral aceptable? ¿Las aplicaciones están configuradas para reconectarse automáticamente tras un failover?
Runbooks: ¿Existen runbooks documentados para cada escenario de desastre relevante? ¿Los runbooks son accesibles incluso si la infraestructura principal está caída? ¿Los runbooks incluyen pasos específicos, puntos de verificación y decisiones de rollback? ¿Se actualizan los runbooks con cada cambio significativo en la infraestructura? ¿El equipo de guardia conoce y ha practicado los runbooks?
Pruebas: ¿Se realizan pruebas de DR con la frecuencia adecuada para cada tier? ¿Los resultados de las pruebas se documentan formalmente, incluyendo RTO/RPO medidos vs declarados? ¿Las deficiencias detectadas en las pruebas se gestionan con acciones correctivas y fechas de implementación? ¿Se ha realizado al menos un gameday en producción para los sistemas más críticos?
Cumplimiento: ¿La estrategia de DR cumple con los requisitos regulatorios aplicables (DORA, NIS2, HIPAA, ISO 22301, etc.)? ¿Los informes de pruebas de DR están disponibles como evidencia de auditoría? ¿Se ha contemplado el escenario de ransomware con backups inmutables y plan de respuesta específico?
Recursos y lecturas recomendadas
Para profundizar en los temas tratados en este capítulo, recomendamos los siguientes recursos. El AWS Well-Architected Framework — Reliability Pillar ofrece una guía exhaustiva de patrones de resiliencia en AWS, con decision trees y ejemplos arquitectónicos. El Azure Architecture Center — Business Continuity proporciona el equivalente para entornos Microsoft, con blueprints descargables para diferentes escenarios de DR. El documento de Google Cloud — Disaster Recovery Planning Guide complementa con la perspectiva de GCP y es especialmente útil para arquitecturas multi-región con Spanner y BigQuery.
Para la ingeniería del caos aplicada a datos, el libro "Chaos Engineering" de Casey Rosenthal y Nora Jones (O'Reilly) sigue siendo la referencia de cabecera, complementado por el más reciente "Learning Chaos Engineering" de Russ Miles que incluye ejemplos prácticos con las herramientas actuales. El curso de DataCamp "Introduction to DevOps" ofrece una buena base para equipos que se inician en prácticas DevOps que incluyen automatización de DR, mientras que en Udemy el curso "AWS Disaster Recovery and High Availability" proporciona laboratorios prácticos específicos para DR en AWS.
En el ámbito regulatorio, el texto completo del Reglamento DORA (UE 2022/2554) es de lectura obligatoria para cualquier organización del sector financiero europeo, y las guías técnicas de la EBA (European Banking Authority) sobre pruebas de resiliencia digital ofrecen orientación práctica sobre cómo cumplir los requisitos. La norma ISO 22301:2019 y su guía complementaria ISO 22313 proporcionan el marco más completo para estructurar un sistema de gestión de continuidad de negocio.
Finalmente, el informe "Cost of Downtime" de ITIC ofrece datos actualizados sobre el impacto económico del downtime por sector y tamaño de empresa, una herramienta útil para construir el business case de la inversión en DR ante el comité de dirección.
Guía de Arquitectura de Datos — Dataprix.com
Capítulo anterior: Observabilidad en la capa de datos — métricas clave, tracing y alerting para bases de datos
Capítulo siguiente: Gestión de esquemas y migraciones en producción — blue/green, feature flags y compatibilidad hacia atrás
