Replicación a nivel de bloque vs. Copia de seguridad a nivel de archivo: ayuda para la toma de decisiones en infraestructuras heterogéneas

En infraestructuras heterogéneas, en el día a día de Backup y DR (Disaster Recovery, es decir, la reanudación tras un fallo grave) a menudo chocan dos mundos: replicación a nivel de bloque y copia de seguridad a nivel de fichero. Ambos suenan a «los datos están seguros», pero resuelven problemas distintos. Quien Block-Level-Replikation vs. File-Level-Backup evalúe de forma rigurosa evita suposiciones típicas como «la replicación es una copia de seguridad» o «un backup de ficheros basta también para bases de datos». Este artículo ofrece una guía de decisión para administradores, System Engineers y proveedores de servicios TI: con prerrequisitos, riesgos, pasos de verificación, implementación y una estrategia realista de retroceso —incluyendo escollos específicos de MariaDB.

Separar términos con claridad: ¿qué se está protegiendo realmente?

Block-Level-Replikation replica bloques de almacenamiento (por ejemplo a nivel de SAN, iSCSI o del storage array) desde un sistema origen a un destino. Opera por debajo del sistema de ficheros: al mecanismo de replicación le es indiferente si el bloque pertenece a un disco de VM, a un fichero de datos de MariaDB o a un fichero de registro. Ventaja: espejado muy rápido de volúmenes completos, con frecuencia con RPOs cortos (RPO = Recovery Point Objective = pérdida máxima de datos en tiempo) y RTOs rápidos (RTO = Recovery Time Objective = tiempo hasta la reanudación del servicio).

File-Level-Backup realiza copias de ficheros y estructuras de directorios (por ejemplo mediante agentes, SMB/NFS, rsync o software de backup), frecuentemente con versionado y retención (Retention). Ventaja: recuperación selectiva de ficheros individuales, mejor control de versiones y, a menudo, mejor integración en conceptos de Inmutable/Air-Gap (protección frente a manipulaciones posteriores).

Importante: ambos enfoques pueden usar snapshots. Un Snapshot es una imagen en un punto en el tiempo (normalmente copy-on-write) de un volumen o sistema de ficheros. Los snapshots no sustituyen a los backups si residen en el mismo almacenamiento o pueden verse comprometidos por el mismo ataque.

Por qué la replicación no es automáticamente una copia de seguridad

La cuestión central no es si los datos existen «en dos sitios», sino si puede volver de forma fiable a un punto en el tiempo definido. La replicación también replica errores: borrados accidentales, cifrado por ransomware, corrupción lógica de datos o un despliegue defectuoso se transfieren de forma fiable y rápida al destino. Eso ayuda a la Alta Disponibilidad (HA), pero para la recuperación suele ser fatal.

Un File-Level-Backup con versiones puede, en muchos casos, sobresalir precisamente aquí: permite retroceder al estado anterior al daño, incluso si el daño fue replicado «de forma limpia». El coste: los backups suelen ser más lentos al RESTaurar sistemas completos, y la consistencia en bases de datos no está garantizada sin un mecanismo adecuado.

Decisión según el objetivo: HA, DR, archivo, cumplimiento

En la práctica ayuda una asignación simple antes de discutir herramientas:

• Alta disponibilidad (HA): El objetivo es un tiempo de inactividad mínimo. La replicación a nivel de bloque o los mecanismos de clúster son eficaces aquí, porque permiten una conmutación rápida.
• Disaster Recovery (DR): El objetivo es la reanudación tras un fallo de ubicación o de almacenamiento. La replicación tiene sentido, pero solo si existe un punto de consistencia “limpio” y una posibilidad de retroceso.
• Backup/RESTore: El objetivo es la recuperación incluso tras errores lógicos o ataques. Copias a nivel de archivo, repositorios de objetos, almacenamiento inmutable y copias fuera del sitio son aquí centrales.
• Archivo/Retención/Conformidad: El objetivo es la conservación a largo plazo, la trazabilidad y la localización. Las copias a nivel de archivo con índice/metadatos y pools de retención separados suelen ser más adecuadas.

En entornos heterogéneos (Windows/Linux, VMs/Bare Metal, NAS/SAN, On-Prem/Cloud, pilas de aplicaciones distintas) casi siempre tiene sentido una combinación: replicación para reanudaciones rápidas de sistemas concretos más backup para rutas de RESTauración versionadas y auditables.

Replicación a nivel de bloque en operación: requisitos y riesgos

La replicación a nivel de bloque funciona bien cuando se dejan claras las suposiciones de infraestructura y operación. Requisitos típicos:

• Identidad & consistencia: El destino debe poder asumir los volúmenes replicados en un estado consistente. Sin un Applikations-Quiesce (breve “congelación” de los accesos de escritura) corre el riesgo de encontrarse con sistemas de archivos o bases de datos inconsistentes.
• Red & latencia: La replicación está impulsada por I/O. El ancho de banda, el RTT (Round-Trip-Time) y la pérdida de paquetes determinan el RPO y la estabilidad. La replicación asincrónica tolera latencia; la síncrona es sensible y puede aumentar las latencias de escritura.
• Protección frente a split-brain: Ante fallos no deben escribirse activamente ambas partes. El split-brain (dos primarios activos) casi siempre conduce a pérdida de datos o a escenarios complejos de fusión.
• Orquestación: El failover no es solo “montar un volumen”. DNS, IPs, load balancer, secrets, certificados, arranques de aplicaciones y dependencias (p. ej. AD, NTP, Monitoring) deben estar definidos en un Runbook o automatizados.

Trampas típicas en infraestructuras heterogéneas:

• Errores de orden: Se conmutan los datastores de VM, pero la base de datos y los servidores de aplicaciones arrancan en orden incorrecto. Resultado: recuperación prolongada y estados inconsistentes.
• Hidden Dependencies: Falta un servidor de licencias, un endpoint PKI interno o un colector de syslog central en el segmento DR — y las aplicaciones se bloquean al iniciar.
• Cadenas de snapshots: Las instantáneas de almacenamiento combinadas con replicación pueden generar largas “cadenas”; eso dificulta los rollbacks y aumenta la sobrecarga de I/O.
• Replicación sin retención: No existe un „volver a ayer 02:00“. Entonces la replicación es solo una vía más rápida hacia el estado incorrecto.

Pasos de verificación para replicación (Preflight)

Antes de vender la replicación como ruta DR (internamente o al cliente), debería marcar al menos estos puntos de comprobación:

• Punto de consistencia definido: ¿Cómo asegura la consistencia de la aplicación (p. ej. DB flush, congelado del sistema de ficheros, snapshot de VM con quiesce)?
• Runbook de failover disponible: ¿Quién hace qué, en qué orden, con qué comprobaciones?
• Reversión (Failback) planificada: ¿Cómo vuelven los datos sin provocar split-brain o largos tiempos de inactividad?
• Capacidad de aislamiento: ¿Puede detener la replicación durante el incidente para preservar un objetivo „limpio“?
• Ventana de prueba: ¿Existen pruebas periódicas (al menos parciales), no solo en papel?

Copia de seguridad a nivel de ficheros en operación: fortalezas, límites, errores típicos

La copia de seguridad a nivel de ficheros es en entornos heterogéneos a menudo la capa base más realista, porque funciona cercana a la plataforma: Windows-servidores, Linux, recursos NAS, datos de aplicación, directorios de configuración. Las grandes ventajas están en el versionado, la RESTauración selectiva y la retención.

Los errores operativos más habituales son menos problemas de herramienta y más problemas de proceso:

• Archivos abiertos y bloqueos: Sin VSS (Volume Shadow Copy Service, servicio de snapshot Windows) u otros mecanismos comparables, los archivos se respaldan „mientras se escriben“. Eso puede resultar inutilizable.
• ACLs y metadatos: Las NTFS-ACLs, permisos POSIX, xattrs (Extended Attributes) o la SMB-Ownership se pierden si la copia de seguridad no soporta metadatos. La RESTauración puede parecer „correcta“, pero los permisos estarán dañados.
• Dominios de RESTauración demasiado grandes: Un único job respalda „todo“. En caso real, la RESTauración tarda demasiado porque faltan priorización y paralelismo.
• Sin prueba de RESTauración: Las copias de seguridad se consideran „verdes“, pero nadie ha verificado si una RESTauración consistente funciona.

Regla práctica: las copias deben reflejar el objetivo de RESTauración

Quien necesite una recuperación rápida del sistema debe combinar copias a nivel de ficheros con copias de imagen/VM. Quien necesite archivos individuales rápidamente (p. ej., PDFs de contrato borrados por error) necesita versionado y búsqueda/índice. Quien tema el ransomware necesita copias inmutables y copias fuera de sitio (offsite), así como credenciales separadas.

MariaDB en foco: por qué la consistencia de la base de datos puede inclinar la balanza

En el ámbito de MariaDB no es raro que la cuestión sea: «¿Cómo recupero un estado consistente y hasta qué punto puedo retroceder en el tiempo?» MariaDB es compatible con MySQL y suele utilizar InnoDB (Storage Engine con registro de transacciones). En bases de datos, una copia de archivos sin pasos coordinados es arriesgada: de lo contrario se respaldan los archivos de datos y los logs en un estado intermedio.

La replicación a nivel de bloques puede funcionar para MariaDB si genera instantáneas consistentes a nivel de aplicación (es decir, deteniendo/forzando brevemente el volcado de las operaciones de escritura de forma controlada) y replica la instantánea. La copia a nivel de archivos puede funcionar si es consciente de la base de datos (p. ej., volcados lógicos para DB pequeñas o backups físicos con una herramienta adecuada).

Escollos típicos de MariaDB en la replicación a nivel de bloques

• Crash-konsistent ist nicht gleich applikationskonsistent: Un snapshot crash-consistente equivale a un «corte de energía». InnoDB puede recuperar muchas cosas, pero no todos los escenarios quedan limpios, y los tiempos de recuperación son difíciles de planificar.
• Binary Logs (Binlog): Para Point-in-Time-Recovery (PITR) necesita Binlogs. La replicación por sí sola no proporciona un «volver a las 10:17», si a las 10:20 ya se ha replicado lo cifrado.
• Version/Migration: Una actualización de MariaDB o una migración de esquema que sea lógicamente errónea se replica. Sin una copia de seguridad versionada no hay un retroceso limpio.

Escollos típicos de MariaDB en las copias a nivel de archivos

• «Einfach /var/lib/mysql kopieren»: Esto suele ser inconsistente en funcionamiento. Aunque a veces «funcione», no es un procedimiento fiable.
• Fehlende Binlogs: Sin Binlogs solo queda «RESTaurar al momento del snapshot». PITR no es posible, el RPO se vuelve mayor.
• RESTore-Probe fehlt: Un backup solo es bueno cuando la RESTauración en una instancia de prueba, incluyendo arranque, comprobaciones y verificación de la aplicación, se puede reproducir de forma fiable.

Matriz de decisión: ¿Cuándo qué procedimiento (o ambos)?

Para el día a día ayuda una matriz pragmática. No teoría, sino lógica operativa:

• RTO muy pequeño (minutos): Replicación a nivel de bloques o replicación de VM + orquestación. Solo a nivel de archivos suele ser demasiado lento para la recuperación completa del sistema.
• RPO muy pequeño (segundos hasta pocos minutos): La replicación es potente, pero solo tiene sentido con un «colchón temporal» adicional (retención de snapshots) o una copia separada; de lo contrario replica el daño.
• Muchos pequeños casos de RESTauración (archivos de usuario): Copia a nivel de archivos con versionado, índice y RESTauración correcta de permisos (ACLs/xattrs).
• Amenaza de ransomware alta: Backups a nivel de archivos/repositorio con almacenamiento inmutable, cuentas separadas y copia fuera de línea/fuera de sitio. La replicación puede complementar, pero no es protección si se cifra sin control durante la misma.
• Heterogéneo, muchas plataformas: Nivel de archivos como capa base; replicación dirigida a pocas cargas de trabajo críticas (p. ej., VMs de bases de datos centrales) y solo con concepto de pruebas y rollback.
• MariaDB con requisito PITR: Backup físico + Binlogs (PITR) u otro procedimiento basado en logs de transacciones. La replicación puede proporcionar el estado base, pero no reemplaza la RESTauración a un punto en el tiempo.

Implementación en la práctica: Puntos de control que debe documentar

Independientemente del producto, los siguientes artefactos son decisivos. Si faltan, la solución en caso de emergencia a menudo no es reproducible:

• Inventario del sistema: ¿Qué volúmenes/comparticiones contienen qué datos (aplicación, BD, logs, uploads, configuración)?
• Clase de protección por carga de trabajo: objetivo RPO/RTO, retención, cifrado, offsite.
• Dependencias: DNS, identidad (AD/LDAP), NTP, certificados, secretos, monitorización, rutas centrales de almacenamiento/red.
• Runbooks: Failover, RESTore, Failback, Stop-the-Bleed (detener la replicación), puntos de comunicación y de aprobación.

Checklist: Prueba mínima de RESTauración (técnicamente válida)

Una prueba de RESTauración no tiene que ser un ejercicio completo, pero necesita criterios claros de éxito:

• Integridad: sumas de verificación/hash o comparaciones de archivos por muestreo (a nivel de archivos).
• Arranque/Inicio: la VM/host arranca, los servicios están en ejecución, los logs son plausibles.
• Comprobación de la aplicación: para MariaDB, p. ej. conexión, consultas simples, consistencia de tablas.
• Tiempo: tiempo de RESTauración medido (real, no estimado).
• Documentación: ¿qué fue distinto respecto a lo esperado? ¿qué dependencia faltó?

MariaDB-How-to: Backup + Binlog-PITR como capa base fiable

Para MariaDB, un enfoque contrastado es: copia física completa periódica más copia continua/regular de los binlogs. Con ello puede retroceder hasta el punto del backup completo y luego reproducir hasta poco antes del error (PITR). En la práctica se usa con frecuencia Percona XtraBackup (backup físico en caliente para InnoDB). Esto no son “internas de framework”, sino oficio operativo: copia consistente, pasos de RESTauración planificables.

Ejemplo de esquema de procedimiento (Linux, genérico; ajustar rutas/usuarios). Muestra deliberadamente la estructura: en producción debe almacenar las credenciales de forma segura (p. ej. en una my.cnf accesible solo por root, Vault o Secrets del agente de backup) y fijar los permisos adecuadamente.

1) Copia completa con XtraBackup (física, consistente)

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

BACKUP_BASE="/backup/mariadb"
TS="$(date +%F_%H%M%S)"
TARGET="$BACKUP_BASE/full_$TS"

mkdir -p "$TARGET"

# Hinweis: Zugangsdaten nicht im Klartext im Skript lassen.
# Nutzen Sie z. B. eine geschützte my.cnf unter /root/.my.cnf

xtrabackup --backup --target-dir="$TARGET"

# Prepare-Schritt macht das Backup RESTorefähig (Redo-Logs anwenden)
xtrabackup --prepare --target-dir="$TARGET"

# Optional: Integritätsmarker
echo "$TS" > "$TARGET/backup.completed"

2) Binlogs sichern (base para recuperación punto en el tiempo — PITR)

Para que PITR funcione, los binlogs deben estar activados y copiarse regularmente a un destino separado y versionado. Los binlogs son los registros continuos de cambios (registro de transacciones/statement), con los que puede reproducir los cambios después de un backup completo.

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

BINLOG_DIR="/var/lib/mysql"
ARCHIVE_DIR="/backup/mariadb/binlogs"

mkdir -p "$ARCHIVE_DIR"

# Alle aktuellen Binlogs auflisten
mysql -N -e "SHOW BINARY LOGS;" | awk '{print $1}' | while read -r f; do
  src="$BINLOG_DIR/$f"
  if [[ -f "$src" ]]; then
    # Kopie mit Metadaten, aber ohne Überschreiben (Versionierung im Repo wäre noch besser)
    cp -n "$src" "$ARCHIVE_DIR/" || true
  fi
done

# Optional: Binlog-Rotation anstoßen (damit ein „abgeschlossener“ Log zum Archiv wandert)
mysql -e "FLUSH BINARY LOGS;"

3) RESTore + PITR (Konzept und Prüfschritte)

Un PITR es tan bueno como su prueba. Al RESTaurar, primero aplica el respaldo completo, inicia MariaDB en un entorno controlado y luego reproduce los Binlogs hasta un momento definido o hasta una posición determinada. Pasos típicos de verificación: arranque sin bucles de crash-recovery, comprobaciones de plausibilidad en los datos de la aplicación y conciliación de la última transacción esperada.

Importante para la decisión «Replicación vs. Backup»: este viaje en el tiempo solo lo consigue con replicación de bloques pura si en el lado de la réplica dispone también de versionado/retención de snapshots y logra aislarse con suficiente rapidez durante el incidente. En la práctica, un repositorio de backups separado suele ser la capa base más robusta.

Realidad del ransomware: Qué puede salir mal en ambos modelos

El ransomware ya no es un caso especial, sino un criterio de diseño. Para ambos enfoques se aplican las siguientes consideraciones:

• Replicación: Los datos cifrados se replican con rapidez. Sin replicación retardada, retención de snapshots en el destino y un proceso de ‚Stop‘ durante el incidente, el objetivo de DR puede quedar inutilizable.
• Backup a nivel de archivos: Las copias de seguridad pueden ser eliminadas o cifradas si los atacantes obtienen acceso a las credenciales de backup o al repositorio. Almacenamiento inmutable (WORM/inmutabilidad), cuentas separadas y copias offline/offsite son determinantes.

Un patrón operativo práctico es: replicación para disponibilidad, backup para recuperabilidad. Además, un incident-runbook ‚Stop-the-bleed‘: detener la replicación, parar los jobs de backup, rotar credenciales, crear una ventana para la forense y luego RESTaurar de forma dirigida desde un punto limpio.

Estrategia de retroceso: Qué hacer si la ruta planificada falla?

Estrategia de retroceso significa planificar el momento en que una RESTauración falla o un failover revela dependencias inesperadas. Un plan sólido se estructura por niveles:

• Nivel 1: Rearranque sobre el estado replicado (rápido, pero persiste el riesgo de errores lógicos).
• Nivel 2: Rollback al snapshot del destino (si existe retención y el snapshot es anterior al incidente).
• Nivel 3: RESTauración desde el repositorio de backups (versionado/inmutable, independiente del storage replicado).
• Nivel 4: RESTauración parcial (p. ej. MariaDB desde PITR, archivos desde versiones, servidores de aplicación reconstruidos desde template/IaC).

Para que esto no quede en teoría, defina de antemano: quién decide el nivel, qué prioridad de datos se aplica (p. ej. primero MariaDB, luego las cargas, luego los informes) y cuál es el tiempo máximo de inactividad aceptable. Especialmente en entornos mixtos, una RESTauración de „todo o nada“ rara vez es óptima.

Recomendación para infraestructuras heterogéneas: Una meta pragmática

Si hoy va a reestructurar o a consolidar una configuración existente, esta visión objetivo es operativa en la práctica:

• Capa base: Backup a nivel de archivos/repositorio con versionado, retención definida y copia offsite (3-2-1 como guía: 3 copias, 2 soportes, 1 offsite).
• Para sistemas críticos: replicación a nivel de bloques (o replicación de VM) con método de consistencia definido y retención de snapshots en el destino.
• Para MariaDB: copia física completa + archivado de Binlogs para PITR, más pruebas periódicas de RESTauración en una instancia de test.
• Operación: monitorización/alertas sobre éxito de los jobs, duración, volumen de datos, ocupación del repositorio y pruebas de RESTauración – no solo «job en verde».

Esto reduce la presión en las pruebas de DR: no tiene que reconstruir cada sistema completamente desde la copia de seguridad cuando la replicación permite continuar trabajando rápidamente. Al mismo tiempo, mantiene la capacidad de retroceder a un punto limpio en el tiempo si el daño lógico ya se ha replicado.

Conclusión: replicación a nivel de bloque frente a copias de seguridad a nivel de archivo no es una cuestión de fe

La decisión replicación a nivel de bloque frente a copias de seguridad a nivel de archivo se toma en infraestructuras heterogéneas mejor en función de los objetivos operativos: la replicación es una palanca potente para RTOs cortos y failover rápidos, pero sin versionado y capacidad de aislamiento también replica el daño. Las copias de seguridad a nivel de archivo proporcionan versiones, RESTauraciones selectivas y una mejor retención, pero fallan si la consistencia (en particular con MariaDB) y las pruebas de RESTauración no se toman en serio.

Si solo va a llevarse una pauta práctica: replicación para disponibilidad, copias de seguridad para recuperabilidad – y pruebe ambos con regularidad, con un runbook claro de „Stop-the-bleed“ y una estrategia de retroceso escalonada.

Para este tema también son importantes las copias de seguridad inmutables y la protección contra ransomware. El artículo sitúa estos aspectos de forma comprensible y muestra qué importa en el día a día.