Disaster Recovery (Recuperación de Desastres y Copias de Seguridad)

1. Visión general del concepto y problema sistémico

En la ingeniería de infraestructura, las fallas de hardware de los SSD, los desastres en los centros de datos de los proveedores, el ransomware y los errores humanos (DROP DATABASE production, accidental rm -rf) no son una cuestión de "si", sino de "cuándo".

La mayoría de los equipos viven en una ilusión de seguridad: añaden una línea en crontab para crear un volcado diario y consideran que la tarea está resuelta. Cuando ocurre un verdadero desastre, se descubre que:

• La última copia de seguridad falló hace tres meses debido a un desbordamiento de disco.
• El volcado contiene datos binarios dañados.
• La recuperación de una base de datos de 100 GB tarda 36 horas, paralizando el negocio (RTO inaceptable).
• Un atacante, al comprometer el servidor, eliminó las copias de seguridad junto con la base de datos activa, ya que la clave API de S3 tenía permisos completos para eliminar (s3:DeleteObject).

Disaster Recovery (recuperación de desastres) es una estrategia integral de continuidad del negocio. No solo abarca la preservación de archivos, sino también objetivos RTO/RPO matemáticamente calculados, almacenamiento inmutable (Immutable Storage) y entrenamientos automáticos regulares para desplegar la infraestructura desde cero.

2. Taxonomía arquitectónica y modelo mental

La matriz arquitectónica de recuperación de desastres se basa en un compromiso entre la velocidad y la frecuencia de fijación del estado:

┌─────────────────────────────────────────────────────────────┐
│                 DISASTER RECOVERY TAXONOMY                  │
├─────────────────────────────────────────────────────────────┤
│ 1. Point-In-Time Recovery (PITR) ➔ RPO ~ segundos            │
│    • Streaming de registros WAL (Write-Ahead Log) en tiempo real│
│    • Herramientas: Litestream (para SQLite), pgBackRest (PG)  │
├─────────────────────────────────────────────────────────────┤
│ 2. Snapshots Dedupe y Encriptados ➔ RPO ~ horas             │
│    • Instantáneas atómicas de datos a través de Restic, BorgBackup, Kopia  │
│    • Cifrado del cliente AES-256 / ChaCha20                  │
├─────────────────────────────────────────────────────────────┤
│ 3. Tier de Almacenamiento Inmutable Offsite (Anti-Ransomware) │
│    • S3 Object Lock (WORM - Write Once, Read Many)          │
│    • Almacenamientos geográficamente aislados (Cloudflare R2, AWS S3) │
├─────────────────────────────────────────────────────────────┤
│ 4. Cold Standby & Automated Recovery Drill (validación de RTO)│
└─────────────────────────────────────────────────────────────┘

1. Recuperación en un punto en el tiempo (Point-In-Time Recovery - PITR):
   • En lugar de un volcado pesado una vez al día, la base de datos transmite continuamente su registro binario de cambios (WAL) a la nube. Esto permite "retroceder" el estado de la base de datos hasta el segundo anterior a la falla o a una consulta errónea del desarrollador (RPO < 10 segundos).
2. Snapshots Dedupe Incrementales (Content-Addressed Snapshots):
   • Utilidades como Restic dividen archivos en bloques criptográficos. Si solo el 1% de una base de datos de 50 GB ha cambiado, solo se cargan los nuevos bloques, ahorrando hasta un 95% de espacio en disco y tráfico de red.
3. Almacenamiento Inmutable (Immutable WORM Storage):
   • La política de seguridad de S3 Object Lock, donde nadie (ni siquiera un administrador con acceso root) puede eliminar o sobrescribir un archivo creado durante un período determinado (por ejemplo, 30 días).
4. Entrenamientos de Recuperación (Recovery Drills):
   • Proceso automático regular en CI que descarga el último archivo de respaldo, lo despliega en un contenedor aislado, ejecuta consultas SQL de verificación y confirma la integridad de los datos.

3. Pipeline técnico y mecánica interna

Ciclo de vida de una copia de seguridad confiable con deduplicación y cifrado:

1. Congelación consistente del estado (Snapshot Lock): La base de datos se pone en modo de preparación para la copia o se crea un snapshot transaccional a través de mecanismos COW (Copy-on-Write) del sistema de archivos ZFS/Btrfs.
2. Cifrado del cliente en el host: Antes de enviarse a la red, los datos se cifran con un algoritmo seguro (AES-256-GCM) utilizando una frase de contraseña conocida solo por el ingeniero. El proveedor de hosting S3 recibe únicamente ruido binario cifrado.
3. Carga paralela en almacenamiento en la nube aislado: Los bloques se transfieren a través de HTTPS a una región geográfica independiente (por ejemplo, un servidor en Alemania se respalda en el almacenamiento de Cloudflare R2 en Suecia).
4. Aplicación de la política de rotación (GFS Retention Policy): El algoritmo mantiene: las últimas 24 copias horarias, 7 diarias, 4 semanales y 12 mensuales (Grandfather-Father-Son), eliminando automáticamente los snapshots intermedios antiguos.
5. Verificación automática de integridad (Automated Integrity Check): Una tarea separada en segundo plano se ejecuta una vez a la semana con el comando restic check --read-data-subset=5%, detectando posible degradación de bits (Bit Rot) en el almacenamiento.

4. Escenarios prácticos de ingeniería en producción

01. Replicación Continua de SQLite con Litestream

Para aplicaciones basadas en SQLite/Turso:

• Litestream opera como un proceso del sistema en segundo plano, interceptando cambios en el archivo WAL.
• Cada 10 segundos, nuevos frames se cifran y se cargan en un bucket de Cloudflare R2.
• En caso de un fallo total del servidor, una nueva máquina se levanta con un solo comando litestream restore -o /var/data/app.db, restaurando el estado del sistema prácticamente sin pérdida de datos (RPO < 10 s, RTO < 60 s).

02. Protección contra atacantes a través de S3 Object Lock

Prevención de la destrucción de la infraestructura por hackers:

• Incluso si un atacante obtiene acceso root completo al servidor y encuentra la configuración con las claves AWS_ACCESS_KEY_ID, intentar ejecutar aws s3 rm --recursive se bloquea por la política de AWS Compliance Lock a nivel de centro de datos de Amazon.
• La empresa garantiza el acceso a copias de seguridad inmutables.

03. Plan de recuperación de reserva fría a través de Terraform (IaC Standby)

Desastre a nivel de OVH (incendio en el centro de datos de Estrasburgo):

• El servidor principal se vuelve físicamente inaccesible.
• El ingeniero inicia un pipeline CI: Terraform alquila una nueva instancia en Hetzner en 3 minutos, Ansible aplica la configuración básica, un script carga la última copia de seguridad de Restic, y los registros DNS de Cloudflare se cambian a la nueva IP en 60 segundos.

5. Errores comunes, trampas y seguridad

• Almacenamiento de la contraseña de descifrado junto a la copia de seguridad: Si la contraseña del repositorio Restic se almacena en un archivo abierto /root/.backup_pass, la compromisión del servidor abre simultáneamente el acceso a los atacantes para leer toda la base de datos del cliente en las copias de seguridad.
• Intento de copiar archivos de bases de datos activas sin bloqueos (Dirty Reads): Simplemente copiar el directorio de datos de PostgreSQL (cp -r /var/lib/postgresql) durante consultas activas crea un estado binario inconsistente (Torn Pages), que no podrá iniciarse después de la recuperación.
• Falta de memoria para descomprimir el volcado: Si en el nuevo servidor se instala un disco de menor tamaño que la base de datos descomprimida, el procedimiento de recuperación fallará a mitad del proceso con un error de falta de espacio en disco (No space left on device).
• Ignorar archivos de configuración y variables de entorno: Hacer una copia de seguridad solo de la base de datos sin guardar configuraciones de Nginx, certificados SSL y archivos .env aumenta el RTO de 15 minutos a varios días de recordar manualmente la configuración.