Recuperación ante desastres: Runbooks, pruebas de failover y comunicación

La recuperación en caso de desastre no es una medida aislada, sino una cadena de decisiones, dependencias y procedimientos practicados con rigor. En la práctica, los reinicios raramente fracasan porque «no existe ninguna copia de seguridad». Con más frecuencia los Runbooks están incompletos, las responsabilidades no están claras, los caminos de failover nunca se han probado en condiciones reales o la comunicación genera presión innecesaria y prioridades equivocadas.

Este artículo está dirigido a administradores, System Engineers, operadores y proveedores de servicios de TI técnicos. El enfoque está en un procedimiento aplicable en la práctica: cómo escribir Runbooks para que funcionen bajo presión, cómo planificar pruebas de failover sin poner en riesgo la producción y cómo establecer la comunicación y las rutas de decisión para que los equipos técnicos puedan seguir actuando. Los ejemplos se orientan en instalaciones típicas de MariaDB (replicación, copias de seguridad, Point-in-Time-Recovery), pero intencionadamente también incluyen temas de infraestructura como DNS, Load Balancer, identidades y Monitoring.

Recuperación en caso de desastre en la práctica

Un «desastre» es operativamente menos un evento puntual que un estado: un servicio no es utilizable, la causa no está clara de inmediato, y la cadena normal de cambios y aprobaciones es demasiado lenta. Desencadenantes típicos son ransomware (incluyendo cuentas de administrador comprometidas), fallo de almacenamiento, errores en actualizaciones, interrupciones del proveedor/cloud, problemas en segmentos de red o corrupción lógica de datos (p. ej., una aplicación defectuosa escribe datos incorrectos).

Los Runbooks suelen fallar por las mismas razones:

• Suposiciones erróneas: „El host de monitoring está activo“, „DNS disponible“, „tenemos conexión a Internet“, „las copias de seguridad son legibles“.
• Pasos demasiado generales: „RESTore DB“ sin indicaciones sobre versión, Recovery-Mode, validación, dependencias y punto de reversión.
• Falta de puntos de decisión: Los Runbooks requieren bifurcaciones claras „si-entonces“ (p. ej., corrupción de datos vs. fallo de infraestructura).
• Comunicación no practicada: El equipo técnico es bombardeado con preguntas de estado, mientras que no se toman decisiones (p. ej., ¿aceptar la pérdida de datos?).

El antídoto es una combinación de (1) Runbooks bien estructurados, (2) pruebas realistas, (3) una distribución clara de roles y (4) reglas de comunicación que apoyen el reinicio técnico en lugar de bloquearlo.

RTO y RPO: definir objetivos antes de escribir un Runbook

Sin valores objetivo, cualquier Runbook será o demasiado conservador (demasiado lento) o demasiado arriesgado (pérdida excesiva de datos). Dos términos son centrales:

• RTO (Recovery Time Objective): Tiempo objetivo hasta que el servicio vuelva a ser utilizable. En la práctica significa: cuándo pueden volver a trabajar los usuarios, no cuándo estará „todo perfecto“.
• RPO (Recovery Point Objective): Pérdida de datos máxima tolerable medida en tiempo. En la práctica: „en el peor caso solo podemos retroceder hasta 15 minutos“.

Para MariaDB esto a menudo significa: el RTO está limitado por la duración del RESTore, la conmutación de DNS/load-balancer, la invalidación del cache de la aplicación y la compatibilidad del esquema. El RPO depende del retraso de replicación, los intervalos de backup y la Point-in-Time-Recovery (PITR, recuperación hasta un punto en el tiempo mediante los binlogs).

Importante: registre RTO/RPO por Service, no «para la base de datos». Una base de datos puede funcionar técnicamente mientras el software de negocio sigue caído por falta de secretos, endpoints incorrectos o jobs rotos.

Runbook-Design: Aufbau, Rollen und „Stop-the-Line“-Regeln

Un Runbook es un manual operativo para la situación de fallo. Debe poder asimilarse en 2–3 minutos y, aun así, ser lo suficientemente profundo para sustentar decisiones y pasos. La siguiente estructura ha demostrado ser eficaz:

1) Header: Zweck, Scope, Voraussetzungen

• Zweck: „Rearranque del MariaDB-Service X tras fallo total del centro de datos primario“.
• Scope: Qué sistemas están incluidos (DB, proxy/load balancer, DNS, monitorización, almacenamiento de backups, secretos)?
• Voraussetzungen: Accesos (Break-Glass-Konten), copias offline, claves/contraseñas, red de emergencia.

2) Rollenmodell: Wer entscheidet, wer führt aus

En caso de desastre la paralelización es decisiva. Defina al menos:

• Líder de incidentes: coordina, prioriza y protege al equipo de cambios de contexto.
• Operador DB: ejecuta los pasos de MariaDB, documenta tiempos y hallazgos.
• Operador Infra: DNS, load balancer, almacenamiento, red, VM/containers, rutas de acceso.
• Comunicación: actualizaciones de estado, partes interesadas, en su caso tickets al proveedor.

Las reglas «Stop-the-Line» deben figurar explícitamente en el Runbook: ¿en qué situaciones se detiene inmediatamente (p. ej. sospecha de ransomware activo, integridad de datos incierta, lagunas inexplicables en los binlogs)? Esto evita un «rearranque» precipitado hacia un entorno aún comprometido.

3) Entscheidungsbaum: Failover oder RESTore?

Los Runbooks no deberían limitarse a listar pasos, sino caminos. Pregunta central: Failover (conmutar a un entorno standby existente) o RESTore (RESTaurar desde backups). Failover suele ser más rápido (RTO), RESTore puede ser más limpio (seguridad/integridad) — especialmente tras ransomware o corrupción lógica.

Technische Grundlagen für MariaDB-DR: Replikation, Backups, PITR

Para MariaDB en operación empresarial son típicos tres componentes:

• Replicación: los sistemas secundarios reciben los cambios de la DB primaria. Según la configuración puede ser asíncrona o semisíncrona. Riesgo: la replicación también transporta cambios «malos» (corrupción, borrados).
• Backups físicos/lógicos: el físico (nivel de archivos, p. ej. procedimientos compatibles con Percona XtraBackup) suele ser más rápido en el RESTore; el lógico (mysqldump) es más portable pero lento con grandes volúmenes de datos.
• PITR (Point-in-Time-Recovery): recuperación hasta un punto entre el backup y el «ahora» mediante binlogs (registros binarios de cambios). Requisito: los binlogs estén completos, sean atribuibles temporalmente y estén disponibles.

Un runbook de DR debe especificar concretamente qué combinación se utiliza: «Failover a Replica A» no es lo mismo que «RESTore del último backup completo + binlogs hasta T-15min». Y: para MariaDB la comprobación de integridad (p. ej. verificar tablas, comprobaciones de integridad de la aplicación) tras el reinicio suele ser el cuello de botella, no la copia de los datos.

Preparación: Qué debe documentarse y estar disponible antes del desastre

Muchos desastres fallan operativamente porque faltan „pequeños detalles“. Esta lista de verificación está deliberadamente escrita de forma pragmática y desde la perspectiva de operaciones:

Identidades y accesos (Break Glass)

„Break Glass“ se refiere a accesos de emergencia que se gestionan por separado de las cuentas administrativas habituales y se protegen especialmente (p. ej., MFA-Token guardados fuera de línea, credenciales selladas, políticas de contraseñas separadas). Para DR importante:

• Acceso SSH/RDP de emergencia a una red administrativa aislada
• Acceso de administrador de BD que no dependa de SSO/IdP (IdP = Identity Provider, inicio de sesión central)
• Acceso al repositorio de backups y al material de claves (cifrado, Object-Storage-Keys)

Inventario de configuración y dependencias

Como mínimo: versiones (MariaDB, OS, Proxy), parámetros (innodb_flush_log_at_trx_commit, binlog_format), topología (Primär/Replica, GTID sí/no), nombres DNS, puertos, reglas de firewall, clases de almacenamiento, comprobaciones de Monitoring, cronjobs/Batch-Jobs. Sin esto, cualquier reinicio se convertirá en una reconstrucción improvisada.

Ruta offline y „No-Internet“

Planifique el caso en que ni Internet ni la consola de la nube estén accesibles. Suena extremo, pero es realista ante fallos de proveedor, problemas BGP o incidentes de seguridad. Medidas prácticas:

• Copia offline de los runbooks (PDF/impreso) y de los secretos más importantes (protegidos)
• Repo/cache local para paquetes o imágenes de contenedor (si no, la reconstrucción fracasará por la descarga)
• Acceso fuera de banda (p. ej. iLO/iDRAC/IPMI o acceso por consola serie) en una red separada

Pruebas de failover: tipos, riesgos y criterios de éxito

Las pruebas de failover no son un „evento“, sino un proceso repetible. Lo decisivo es definir criterios de éxito que vayan más allá de un „ping responde“. Para MariaDB y servicios dependientes, las pruebas deberían cubrir como mínimo: acceso de lectura/escritura, consistencia de transacciones, inicio de sesión en la aplicación, jobs/colas críticos, reporting, así como Monitoring/Alerting.

Tipos de prueba (de seguro a realista)

• Tabletop/Walkthrough: El equipo repasa el runbook sin modificar sistemas. Bueno para roles y comunicación, pobre para detalles técnicos.
• Failover simulado en Test/Staging: Valioso técnicamente, pero a menudo con volúmenes de datos/perfiles de carga distintos.
• Failover planificado en producción: Alto valor de aprendizaje, pero debe prepararse adecuadamente (ventana de mantenimiento, rollback, partes interesadas).
• Simulación de failover no planificada: Enfoque de „caos“ con elementos sorpresa. Solo para equipos maduros y automatización estable.

Trampas típicas en failover de MariaDB

• Replica lag: La demora en la replicación conduce a un RPO mayor del esperado. Causas comunes: cuellos de botella de I/O o transacciones grandes.
• Separación lectura/escritura: Aplicaciones o proxies (p. ej. ProxySQL) usan endpoints distintos; tras un failover siguen escribiendo en modo «read-only» o en la dirección equivocada.
• DNS-TTL: Una TTL demasiado larga (Time To Live, duración de caché) retrasa la conmutación. Una TTL demasiado corta incrementa la carga y la propensión a fallos.
• Deriva GTID/posición: Si la topología y la posición de replicación no están documentadas con claridad, existe riesgo de split-brain (dos sistemas primarios).
• Regresión de seguridad: Cambios de emergencia que eluden el endurecimiento (firewall «brevemente abierto», permisos de usuario mal configurados).

Prueba mínima de failover (práctica, 60–120 minutos)

Si dispone solo de ventanas de mantenimiento limitadas, priorice una prueba que ofrezca la máxima utilidad práctica:

1. Congelación de cambios: Detener despliegues, pausar jobs por lotes, reducir la carga de escritura.
2. Comprobar estado de réplicas: Replicación en proceso de „catch up“, documentar el lag.
3. Conmutación: Apuntar el endpoint de la aplicación a la réplica; dejar el primario en read-only o aislarlo.
4. Comprobaciones de sanidad: Inicio de sesión, prueba de lectura/escritura, los informes/jobs más críticos.
5. Rollback: Volver atrás o mantener el nuevo primario, pero decidir de forma clara.
6. Trabajos posteriores: Crear tickets para las brechas encontradas, actualizar el runbook, registrar los tiempos.

Runbook de RESTauración para MariaDB: secuencia de pasos, comprobaciones, estrategia de retroceso

La RESTauración es el camino „duro“, porque contiene más incógnitas: consistencia del backup, claves, rendimiento al RESTaurar y, sobre todo, la validación. Un buen runbook de RESTauración separa de forma estricta: recuperación (RESTaurar los datos) y puesta en servicio (hacer que el servicio sea utilizable).

Fase 1: Aclarar la situación y definir el estado objetivo

• Clase de incidente: ¿Fallo de infraestructura, corrupción de datos, incidente de seguridad (p. ej. ransomware)?
• Punto objetivo: ¿“Último backup consistente“ o PITR hasta el instante T?
• Decisión de riesgo: Compensación RPO (pérdida de datos) vs. RTO (tiempo). Esta decisión debe tomarse de forma consciente y documentarse.

Especialmente en casos de corrupción lógica, el failover a una réplica es peligroso porque los cambios incorrectos ya se replicaron. En esos casos, el RESTore/PITR suele ser la vía segura.

Fase 2: Provisión de infraestructura (sin atajos)

La RESTauración suele fallar por aspectos aparentemente simples: versiones de paquetes incorrectas, parámetros de kernel ausentes, opciones del sistema de ficheros diferentes, volúmenes demasiado pequeños o ajustes InnoDB incompatibles. Documente en el runbook:

• Forma objetivo: VM, bare metal, contenedor (y qué clase de almacenamiento)
• Capacidad: datos + sobrecarga (overhead) para la RESTauración (temporalmente con frecuencia mucho mayor)
• Red: segmento, firewall, solo puertos necesarios abiertos
• Sincronización de tiempo: NTP/Chrony (importante para logs, referencia temporal del binlog, auditorías)

Fase 3: Localizar la copia de seguridad, verificarla y dejarla RESTaurable

La verificación es obligatoria. “Copia de seguridad presente” no es prueba de “copia de seguridad legible”. Compruebe al menos: existencia, tamaño/tendencia, sumas de verificación, claves de cifrado, permisos de acceso y si la copia de seguridad se creó de forma consistente.

Ejemplo: Un paso de comprobación sencillo, independiente del repositorio, para archivos de archivado (integridad y capacidad de extracción) podría ser el siguiente:

#!/usr/bin/env bash
set -euo pipefail

BACKUP_TAR="/mnt/backup/mariadb-full-2026-07-28.tar.gz"
SHA_FILE="${BACKUP_TAR}.sha256"

# 1) Prüfsumme verifizieren
sha256sum -c "$SHA_FILE"

# 2) Archiv testweise lesen (ohne zu extrahieren)
tar -tzf "$BACKUP_TAR" > /dev/null

echo "Backup-Archiv ist lesbar und Prüfsumme passt."

Por qué funciona: las sumas de verificación detectan errores silenciosos de bits; la comprobación de lista del archivo tar detecta compresión defectuosa o estructuras de contenedor dañadas. Cuándo falla: cuando la copia de seguridad está íntegra como archivo, pero es inconsistente en su contenido (p. ej., no hay un snapshot limpio, faltan tablespaces, binlogs incompletos). Por eso se necesita además validación a nivel de la base de datos (véase más abajo).

Fase 4: Ejecutar la RESTauración (física/lógica) y validar a continuación

El método concreto de RESTauración depende de su procedimiento de copia de seguridad. Para el runbook son puntos de control universales:

• Arrancar la DB en un estado controlado: no dejar aplicaciones conectadas; sólo permitirlas una vez que la validación haya sido superada.
• Fase de solo lectura: primero sólo lectura/comprobación, luego habilitar para carga de escritura.
• Comprobaciones de esquema/migración: ¿El esquema coincide con la versión de la aplicación? Si no, pueden producirse errores secundarios.

Un bloque SQL práctico para comprobaciones rápidas de plausibilidad (sin profundizar en las internas del motor):

-- Verbindung und Grundzustand
SELECT VERSION() AS mariadb_version;
SHOW VARIABLES LIKE 'read_only';
SHOW VARIABLES LIKE 'innodb_flush_log_at_trx_commit';

-- Replikations-/Binlog-Relevanz (falls genutzt)
SHOW VARIABLES LIKE 'log_bin';
SHOW BINARY LOGS;

-- Grobe Konsistenzsignale: Tabellenstatus und Fehler
SHOW DATABASES;
-- Für ausgewählte Kern-Tabellen (Beispielnamen anpassen):
CHECK TABLE app.core_customer;
CHECK TABLE app.core_order;

Por qué ayuda: comprueba si está en la versión esperada, si el servidor es accidentalmente escribible, si existen binlogs (relevante para PITR y replicación posterior) y si las tablas centrales parecen al menos superficialmente consistentes. Límites: CHECK TABLE no es una panacea, e InnoDB puede mostrar ciertos problemas sólo bajo carga. Complementelo por tanto con comprobaciones de sanidad de la aplicación (login, procesos centrales, informes críticos).

Fase 5: Ejecutar correctamente PITR (Point-in-Time-Recovery)

PITR significa: RESTaurar una copia de seguridad completa y luego aplicar los binlogs hasta un punto temporal definido. Para que esto funcione, los binlogs deben ser completos y temporalmente inequívocos. Riesgos típicos:

• Zonas horarias/deriva del reloj: el desfase temporal dificulta la decisión sobre el «momento de parada».
• Lagunas en los binlogs: archivos faltantes por retención, fallos de almacenamiento o offloading incorrecto.
• Punto objetivo impreciso: el negocio dice “antes del error”, pero el momento del error no está correlacionado con precisión (¡logs!).

En el runbook debería prever: (1) línea temporal extraída de monitoring/los logs de la aplicación, (2) definición clara de „último commit bueno“, (3) secuencia de comandos documentada acorde con sus herramientas. Si emplea mysqlbinlog, pruebe el procedimiento regularmente en un entorno aislado, porque pequeños errores de parámetros (p. ej. interpretación errónea de GTID) suelen detectarse solo en el caso real.

Fase 6: Estrategia de retroceso (rollback) para la RESTauración

Una RESTauración puede fallar: copia de seguridad corrupta, clave incorrecta, la RESTauración tarda más que el RTO, o falla la validación. Por ello, no planifique el retroceso como „seguiremos intentando“, sino como una opción definida:

• Plan B Failover: Si la RESTauración tarda demasiado, conmutar a una réplica aceptando la pérdida de datos.
• Plan C Operación mínima: Modo de solo lectura para funciones núcleo (p. ej. reporting) con comunicación clara.
• Ruta forense: En caso de incidente de seguridad: aislar sistemas, no realizar „acciones de limpieza“ sin autorización.

Comunicación en caso de desastre: ritmo, contenidos, registro de decisiones

La comunicación en emergencia es un factor técnico, ya que define el enfoque y el rendimiento. Un patrón probado es un ritmo fijo de actualizaciones (p. ej. cada 15–30 minutos) y un formato de estado uniforme. Esto reduce las consultas y evita declaraciones contradictorias.

Plantilla de estado (breve, pero robusta)

• ¿Qué está afectado? Servicio/alcance, impacto para el usuario.
• ¿Qué se conoce? Causa como hipótesis, no como afirmación.
• ¿Qué estamos haciendo ahora? Paso concreto (failover en curso, RESTauración en marcha, validación).
• ¿Cuál es el riesgo? ventana de pérdida de datos (RPO), riesgo de integridad, riesgo de seguridad.
• ¿Cuándo la próxima actualización? momento fijo.

Lleve en paralelo un registro de decisiones: ¿Quién decidió y cuándo aceptar qué compromiso RPO/RTO? No es burocracia, protege al equipo posteriormente y ayuda en auditorías.

Errores de comunicación

• La técnica se vuelve un ‚live-ticker‘: Un operador no debería simultáneamente ejecutar la RESTauración y atender a las partes interesadas.
• Precisión falsa: „En 12 minutos volverá a estar online“ suele ser poco fiable. Mejor: „RESTauración en curso, siguiente hito: validación en aprox. 30–45 minutos; luego ETA“.
• No hay un ‚Go‘ claro: ¿Quién autoriza que se permita volver a escribir? Ese es un punto de decisión definido.

Pasos de verificación y troubleshooting: cuando el failover/RESTauración no funciona según lo previsto

En reanudaciones reales suele tratarse de pocas clases de errores recurrentes. Por eso, un buen runbook incluye bloques de troubleshooting breves con «síntoma → verificación → medida».

Síntoma: la aplicación no se conecta a la BD después del failover

• Verificación: ¿El DNS sigue apuntando al endpoint antiguo? ¿TTL/caché? ¿Comprobaciones de estado del balanceador de carga?
• Verificación: ¿Reglas de firewall en el segmento DR? ¿Security Groups? ¿NAT?
• Medida: Verificar nombre → IP, alcanzabilidad del puerto, y después comprobar la configuración/secretos de la aplicación.

Un chequeo de red rápido desde un host de la aplicación (ejemplo) puede ser así:

#!/usr/bin/env bash
set -euo pipefail

DB_FQDN="db.service.example"
DB_PORT="3306"

echo "DNS-Auflösung:";
getent hosts "$DB_FQDN" || true

echo "Port-Test:";
( echo > /dev/tcp/$DB_FQDN/$DB_PORT ) && echo "Port offen" || echo "Port blockiert/timeout"

Por qué ayuda: separa la resolución de nombres de la accesibilidad de puertos. Dónde falla: /dev/tcp es específico de bash y no está disponible en todas partes; en tales entornos necesita nc/telnet u otras herramientas adecuadas.

Síntoma: la réplica está en read-only tras un failover o se comporta de forma inconsistente

• Check: ¿read_only/super_read_only configurado? (En algunos montajes HA es intencional.)
• Check: ¿La configuración de replicación sigue activa y continúa escribiendo «por detrás»?
• Medida: Establecer claramente la función primaria; poner los demás nodos en read-only y/o volver a conectar como réplicas.

Síntoma: la RESTauración tarda «interminable»

• Check: Rendimiento del almacenamiento (IOPS/throughput), cuellos de botella de CPU, compresión/desencriptación.
• Check: Volumen de destino demasiado pequeño o sistema de archivos incorrecto (p. ej. noatime, opciones de journaling).
• Medida: Paralelizar solo donde las herramientas y el almacenamiento lo soporten; en caso contrario activar el Plan B.

Hacer medible la calidad del runbook: «Definition of Done» para DR

Si no, los runbooks se convierten en documentos que nadie quiere tocar. Defina criterios de calidad objetivos:

• Ejecutable en la práctica: Todos los accesos, rutas y dependencias están disponibles (incl. sin conexión).
• Probado: Cada variante crítica del runbook (Failover, RESTore, PITR) se ha ensayado al menos una vez.
• Marca temporal: última prueba, última modificación, rol responsable.
• Validación: Criterios de aceptación claros sobre cuándo se considera «servicio RESTaurado».
• Reversión: Para cada paso importante existe una opción de rollback.

Para MariaDB se recomienda además un ritmo fijo: pequeñas pruebas de RESTauración (p. ej. mensuales) con datos mínimos y un ejercicio integral de extremo a extremo (p. ej. trimestral o semestral) según la tasa de cambios y el riesgo.

Conclusión práctica: la recuperación ante desastres es una operación de operación ensayada

En caso de desastre ganan los equipos que han tomado decisiones por adelantado: RTO/RPO por servicio, rutas claras de Failover vs. RESTore, accesos asegurados y un esquema de comunicación que proteja la operación técnica. Un runbook deja de ser mera «documentación» y pasa a ser una herramienta: hace los pasos reproducibles, reduce errores bajo estrés y permite extraer mejoras concretas de cada prueba.

Si solo se queda con un punto: no planifique la recuperación como un «tema de backups», sino como un arranque de extremo a extremo que incluya DNS, identidades, secretos, tareas (jobs), monitorización y procesos de aprobación. Solo cuando las pruebas de failover y las pruebas de RESTauración funcionen regularmente, la recuperación ante un desastre será algo más que una esperanza.

En este ámbito también son importantes el runbook de Disaster Recovery y la comunicación de incidentes. El artículo sitúa estos aspectos de forma comprensible y muestra en qué fijarse en la operación diaria.