Automatizar las comprobaciones diarias de integridad de las copias de seguridad: pruebas de RESTauración rápida para rutas de datos críticas

Backup-Sanity-Checks son pruebas breves de RESTauración rápida automatizadas que confirman diariamente que las rutas de datos críticas son realmente RESTaurables. El objetivo no es una ejecución completa de Disaster Recovery, sino una prueba de humo rápida y reproducible que abarque claves, transporte, descifrado y comprobaciones mínimas de plausibilidad. Esta entrada está dirigida a administradores, System Engineers y operadores y explica los prerequisitos, errores típicos, secuencias de verificación concretas y una estrategia de retroceso práctica — con especial atención a MySQL.

Backup-Sanity-Checks: Por qué un trabajo de backup exitoso no es suficiente

Las herramientas de backup suelen informar únicamente si se escribió un artefacto. Eso no dice nada sobre la ruta de RESTauración: ¿dónde están las claves? ¿sigue abierta la ruta de red? ¿se incluyen metadatos como ACLs o xattrs? En particular MySQL puede producir un volcado aparentemente correcto que tras la importación resulta lógicamente inutilizable (p. ej. tablas faltantes, errores de collation o binlogs incompletos para PITR — Point in Time Recovery, es decir, recuperación hasta un punto en el tiempo).

Objetivos, términos y enfoque

Alinee las pruebas con RPO y RTO: RPO (Recovery Point Objective) es la pérdida máxima de datos tolerable; RTO (Recovery Time Objective) el tiempo permitido de recuperación. Las rutas de datos críticas son los artefactos y pasos mínimos para RESTaurar un servicio de forma controlada: esquema de la base de datos, últimos binlogs, configuración, certificados y un pequeño conjunto de datos de referencia para la verificación de plausibilidad.

Principios de arquitectura para pruebas diarias de RESTauración rápida

Una automatización exitosa sigue tres principios:

• Aislamiento: RESTaurar en una sandbox propia (VM, contenedor, Namespace, VLAN). Sin conexiones salientes hacia producción.
• Reproducibilidad: mismos artefactos, mismo descifrado, mismas herramientas de RESTauración que en el incidente real.
• Control de costes: volúmenes de datos limitados, timeouts estrictos, limpieza automática.

Diseño de extremo a extremo: cinco pasos de un Sanity-Check

1) Selección del artefacto a probar

Seleccione siempre la copia de seguridad más reciente que haya sido exitosa (o la más reciente que cumpla el RPO). De lo contrario, las pruebas pueden informar falsamente en verde aunque las copias reales fallen.

2) Recuperación y descifrado

La prueba debe usar la misma cadena de descifrado que el runbook de producción (p. ej. KMS/Vault/Tokens). Si falta el acceso a la clave, la prueba deberá fallar (estado rojo). Verifique también la rotación de claves: ¿se sigue leyendo la clave antigua o sólo está disponible la nueva?

3) RESTauración en una sandbox aislada

Use puertos dedicados, directorios de datos y políticas dedicados. Los límites (CPU/RAM/IO) hacen que los tiempos de RESTauración sean comparables. El aislamiento también reduce el riesgo de que la prueba afecte a sistemas de producción.

4) Comprobaciones de integridad y plausibilidad

Compruebe más que los códigos de salida: hashes de archivos, número de ficheros, propietario/ACLs; en MySQL: arranque del servidor, esquemas/tablas esperados y consultas de lectura definidas (COUNT, MAX(timestamp)). Las consultas a information_schema proporcionan señales rápidas y fiables.

5) Métricas, registro y limpieza

Almacenar por ejecución: Backup-ID, hora de inicio/fin, volumen de datos, duración de la RESTauración, códigos de salida, estado detallado de cada verificación. La sandbox debe eliminarse incluso en caso de errores.

Requisitos previos antes de la automatización

Runbook como fuente de la verdad

La automatización debe reflejar el runbook, no al revés. Aclare el orden, los puertos, la ruta de los secrets y qué hacer si falta algún artefacto. Un runbook incluye también los canales de comunicación y las responsabilidades para las escalaciones.

Identity und Secret‑Handling

Las cuentas de servicio para pruebas necesitan principios de mínimos privilegios (least‑privilege), tokens con vigencia limitada y auditoría de logs. Un archivo de contraseñas sin cifrar es inaceptable. Utilice Hashicorp Vault, AWS KMS o un sistema similar con tokens de corta duración; la automatización debe disponer de mecanismos para la actualización automática (auto‑refresh).

Netzwerkplanung

Throttling y QoS evitan que las pruebas interfieran con las ventanas de backup de otros sistemas. El bloqueo de egress previene fugas accidentales de datos; el sandboxing de DNS (resolver propio) evita que las pruebas activen webhooks externos.

Datenschutz und Testdaten

Si datos productivos se copian a una sandbox, la protección de accesos y la retención deben ser correctas. Alternativamente, emplee subconjuntos representativos o Golden Files sintéticos. El enmascaramiento o la seudonimización son prácticas habituales cuando están implicados datos personales.

Backup-Sanity-Checks für MySQL (Fokus)

MySQL distingue, de forma general, entre logical Backups (mysqldump; sentencias SQL individuales) y physical Backups (p. ej. Percona XtraBackup o snapshots a nivel de bloque). Los dumps lógicos son más portables y a menudo más prácticos en pruebas rápidas; no obstante, los backups físicos deberían cubrirse de forma rotativa si se utilizan en un caso real.

Welche MySQL‑Prüfungen sind sinnvoll?

Para comprobaciones diarias de sanidad son ideales pruebas ligeras y significativas:

• Arranque del servidor en la sandbox: mysqld o el contenedor Docker se inicia y acepta conexiones.
• Disponibilidad del esquema: número de tablas esperado vía information_schema.
• Consultas de referencia de negocio: 3–5 consultas de lectura predefinidas (p. ej. COUNT, MAX(timestamp), checksums).
• Prechequeo de PITR: los binlogs son legibles y se comprueban errores de checksum.
• Metadatos: permisos, stored procedures, events y triggers presentes.

Praktische SQL‑Checks

Estas consultas son rápidas y significativas; ajuste los nombres a su entorno.

-- Anzahl Tabellen im Schema prüfen
SELECT COUNT(*) AS tables FROM information_schema.tables WHERE table_schema = 'app_db';

-- Stichprobe in einer kritischen Tabelle
SELECT COUNT(*) AS rows, MAX(updated_at) AS last_change FROM app_db.orders;

-- Server‑und InnoDB‑Version
SELECT @@version AS mysql_version, @@innodb_version AS innodb_version;

-- Kurzer Konsistenzcheck für eine Tabelle
CHECK TABLE app_db.users QUICK;

Beispiel: SchnellRESTore mit mysqldump in einer Docker‑Sandbox

Una forma rápida de comprobar un dump es con un contenedor Docker aislado y con su propio mapeo de puertos:

# Start einer isolierten Testinstanz (lokal, Port 3307)
docker run --rm --name mysql-test -e MYSQL_ROOT_PASSWORD="sicheresPasswort" -d -p 3307:3306 mysql:8.0

# Import (aus dem zuvor heruntergeladenen Dump)
mysql --host=127.0.0.1 --port=3307 --user=root --password="sicheresPasswort" < /tmp/mysql-dump.sql

# Beispiel: Prüfen, ob Schema vorhanden ist
mysql --host=127.0.0.1 --port=3307 --user=root --password="sicheresPasswort" -e "SELECT COUNT(*) FROM information_schema.tables WHERE table_schema='app_db';"

# Stoppen des Containers nach dem Test (Cleanup wird empfohlen)
docker stop mysql-test

PITR‑Vorprüfung mit mysqlbinlog

Para comprobar si los Binlogs son útiles para un caso de uso PITR, lea los Binlogs y verifique las Checksums. Un flujo de Binlog legible es un indicio sólido de que una Point‑in‑Time‑Recovery es posible.

# Binlog auf Lesbarkeit prüfen
mysqlbinlog --verify-binlog-checksum /path/to/binlog.000001 >/dev/null

# Beispiel: Auszugsweises Anwenden eines Binlog‑Zeitfensters
mysqlbinlog --start-datetime="2026-07-27 00:00:00" --stop-datetime="2026-07-27 01:00:00" /backup/binlogs/binlog.000001 | 
  mysql --host=127.0.0.1 --port=3307 --user=root --password="sicheresPasswort"

Robuste Skripte: Fehlerhandling, Timeouts und Cleanup

Ein Sanity‑Runner muss auch bei Fehlern sauber aufräumen. Nutzen Sie set -euo pipefail, trap für limpieza y códigos de salida definidos para la alarma automatizada.

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

RUN_ID="$(date -u +%Y%m%dT%H%M%SZ)"
WORKDIR="/var/tmp/backup-sanity-${RUN_ID}"
LOGFILE="/var/log/backup-sanity/backup-sanity-${RUN_ID}.log"
mkdir -p "${WORKDIR}" "$(dirname "${LOGFILE}")"

log(){ printf '%s %sn' "$(date -u +%Y-%m-%dT%H:%M:%SZ)" "$*" | tee -a "${LOGFILE}"; }
cleanup(){ log "Cleanup: ${WORKDIR}"; rm -rf "${WORKDIR}" || true; }
trap cleanup EXIT

log "Starting backup sanity ${RUN_ID}"
# Backup‑ID ermitteln (Beispiel: API oder lokale Datei)
BACKUP_ID="$(cat /var/lib/backup/latest_successful_backup_id 2>/dev/null || true)"
if [[ -z "${BACKUP_ID}" ]]; then log "ERROR: no backup id"; exit 10; fi
log "Selected backup ${BACKUP_ID}"

# Beispiel: Dump herunterladen (ersetzt durch Repo‑API)
# repo-cli fetch --id "${BACKUP_ID}" --target "${WORKDIR}/mysql-dump.sql"

DUMP_FILE="${WORKDIR}/mysql-dump.sql"
if [[ ! -s "${DUMP_FILE}" ]]; then log "ERROR: dump missing"; exit 21; fi

# Start Test‑DB (lokal, Port 3307) - hier als Beispiel mit systemd‑Unit oder docker
# Weiterer Code: Import, Prüfungen, Metrikaufzeichnung
log "Import complete, running SQL checks"

Erweiterte MySQL‑Troubleshooting bei RESTore‑Fehlern

Charakterset- und Collation-Probleme

Síntoma: la importación tiene éxito, pero los textos son incorrectos o las comparaciones fallan. Causa: diferentes configuraciones de conjunto de caracteres en el volcado y en el servidor de destino. Compruebe SHOW VARIABLES LIKE 'character_set%'; y utilice en el dump --default-character-set=utf8mb4.

Fehlende Binlogs oder GTID‑Inkompatibilitäten

Si su entorno de producción utiliza GTIDs y su servidor de pruebas no, la aplicación de los Binlogs puede fallar. Compruebe el estado de GTID y ajuste las opciones correspondientes al importar (p. ej. SET @@SESSION.SQL_LOG_BIN=0; para pruebas no replicantes).

InnoDB‑Tablespace/LSN‑Probleme bei physischen Backups

Los backups físicos (XtraBackup) deben prepararse (xtrabackup --prepare) para que los logs de InnoDB sean consistentes. Compare el LSN (Log Sequence Number) en el manifiesto del backup con el LSN del servidor en ejecución; un desajuste puede impedir el arranque del servidor.

# XtraBackup vorbereiten
xtrabackup --prepare --target-dir=/backup/dir

# LSN anzeigen (Beispiel aus Backup‑Log)
grep -i 'innodb_lsn' /backup/dir/xtrabackup_info || true

Monitoring, Alarmierung und Trendanalyse

Registre métricas por ejecución:

• Éxito/Fallo (binario)
• Duración de la RESTauración (segundos)
• Volumen de datos transferido
• Categoría de fallo (Key, Fetch, Import, Validation)

Visualice estas métricas en Grafana/Prometheus o en su Monitoring‑Stack. Establezca reglas de escalado: advertencia ante 1 error, ticket ante 2 errores consecutivos, incidente ante 3. Analice tendencias: un aumento de la duración del RESTore puede indicar degradación del storage o problemas de red.

Escollos que con frecuencia se pasan por alto

1) Backups inmutables frente a rotación de claves

Las copias de seguridad inmutables protegen frente a la eliminación, pero si las claves se rotan y las claves antiguas dejan de ser accesibles, las copias son inútiles. Las pruebas deben validar la pérdida de claves y los accesos históricos.

2) Cuotas de almacenamiento y artefactos parciales

Algunos trabajos de backup escriben hasta que se alcanza una cuota y se interrumpen sin devolver código de error. Compruebe tamaños de archivo y completitud mediante hashes.

3) Exclusiones meta ocultas

Las exclusiones automatizadas (p. ej. mediante .backupignore) pueden omitir archivos críticos. Los Sanity‑Checks deberían supervisar esas exclusiones y, de forma ocasional, verificar copias de seguridad completas.

Estrategia de retroceso: Qué hacer cuando las pruebas están en rojo

Medidas inmediatas (primeros 30–60 Minuten)

• Análisis de logs: Runner, Backup‑ID, mensajes de error
• Reintentar en otro Runner/región para descartar problemas del Runner
• Comprobar accesibilidad del Key‑Store y del repositorio

Estabilización el mismo día

• Marcar la última copia conocida buena y, si procede, designarla como fuente preferente
• Ajuste temporal de los trabajos de backup (p. ej. copia completa en lugar de incremental)
• Comunicación a los equipos afectados con medidas y duración estimada

Corrección sostenible

• Ajustar el runbook, ampliar los checks (p. ej. checksums adicionales, limpieza de binlogs)
• Análisis de causa raíz: ¿por qué falló la prueba? ¿Infraestructura? ¿Rotación de claves? ¿Bug del repositorio?
• Planificar ejercicios regulares de DR a mayor escala

Operacionalización: Roles, responsabilidades, documentación

Los Sanity‑Checks actúan como un contrato claro y medible entre los equipos de Backup, DB‑ y plataforma: entrega de artefactos, pasos de RESTore y operación de la sandbox son responsabilidades separadas con métricas definidas. Documente los siguientes puntos:

• Owner de los Test‑Runner y sus permisos
• Ruta a Keys/Secrets y fechas de rotación
• Lista de contactos en caso de errores de comprobación
• Versionado oficial del Runbook

Lista de verificación de ejemplo para la automatización diaria

1. Runner arranca y obtiene la Backup‑ID más reciente
2. Recuperación & descifrado exitosos
3. RESTore en sandbox dentro de los timeouts definidos
4. 3–5 comprobaciones SQL predefinidas superadas
5. Preverificación de PITR: binlogs legibles
6. Metadatos (ACLs, xattrs, Procs) muestreo exitoso
7. Informe generado, métricas publicadas
8. Limpieza realizada

Conclusión

Los Backup‑Sanity‑Checks regulares y automatizados aumentan la probabilidad de poder RESTaurar realmente en un incidente. Comience pequeño (Subset‑RESTore, pocas comprobaciones robustas), aisle y mida de forma constante. Especialmente con MySQL: una RESTauración se considera “verde” solo cuando la instancia arranca y las comprobaciones de plausibilidad definidas devuelven resultados coherentes —no solo cuando la herramienta de backup informa éxito. Documente Runbooks, automatice métricas y establezca rutas de escalado. Así evita que las copias de seguridad queden como meros artefactos y no sean utilizables en caso de necesidad.

Backup‑Sanity‑Checks en CI/CD e infraestructura como código

Integre comprobaciones de integridad de backup en sus pipelines de despliegue: una RESTauración rápida fallida debe bloquear los despliegues o desencadenar un rollback rápido. Para ello, establezca una matriz de compatibilidad clara (versión de la herramienta de backup, versión principal de MySQL, formato de volcado). Use infraestructura como código para aprovisionar la sandbox de forma reproducible (Terraform/Ansible), de modo que los errores de RESTauración no se deban a entornos de prueba efímeros.

Guarde por prueba un manifiesto (ID de backup, versión de clave, versión de la herramienta, suma de comprobación) – eso facilita los análisis de causa raíz y la reproducibilidad. Automatice la generación de tickets ante fallos y mida los SLA para las comprobaciones de integridad (p. ej., tiempo hasta la confirmación del error). Planifique ejercicios completos de DR periódicos además de pruebas rápidas diarias: solo así verificará dependencias y procesos organizativos que las comprobaciones automatizadas no pueden cubrir.

Para este tema también son importantes las pruebas de RESTauración rápida y la validación de RESTauraciones. El artículo sitúa estos aspectos de forma comprensible y muestra qué importa en el día a día.