Backups y recuperación de desaster

Backups y Recuperación de Desaster

1) Definiciones y objetivos

Backup es una copia coherente de los datos/configuraciones para su posterior recuperación (desde borrados accidentales, bugs, cryptolocers, catástrofes).
DR (Disaster Recovery) es un proceso para restaurar la infraestructura/servicios a los trabajadores de SLO después de un accidente importante (incendio, pérdida de región, compromiso masivo).
RPO (Recovery Point Objective) es la pérdida de datos máxima permitida en el tiempo (por ejemplo, 15 minutos).
RTO (Recovery Time Objective) - Tiempo objetivo de recuperación del servicio (por ejemplo, 30 minutos).

Principio clave: replicación ≠ retroceso. La replicación «difumina» rápidamente los errores y el cifrado en todas las copias. Backup es una copia aislada, validada, potencialmente inmutable.

2) Clasificación de datos y niveles de criticidad

Dividir los activos en clases:

Tier-0 (vitales): DAB transaccional, pagos, contabilidad de balances, secretos/PKI.
Tier-1 (crítico): confecciones de servicios, colas, artefactos CI/CD, registros de contenedores.
Tier-2 (importantes): análisis, informes, índices secundarios, archivos de registro.
Tier-3 (auxiliar): cachés, datos temporales (se puede restaurar mediante reconstrucción).

Para cada clase, defina RPO/RTO, vida útil, requisitos de inmutabilidad y ubicación.

3) Estrategias de almacenamiento: regla 3-2-1-1-0

3 copias de datos (prod + 2 copias de seguridad).
2 tipos diferentes de medios/almacenamiento.
1 copia offsite (otra región/nube).
1 immutable/air-gap (WORM/Object Lock/Tape).
0 errores en las comprobaciones de recuperación (pruebas regulares).

4) Tipos de respaldo

Full es una copia completa. Lento/caro, pero base para todas las estrategias.
Incremental es la diferencia con el último backup. Óptimo en volumen.
Differential es la diferencia con el último full. Más rápido de recuperación, más espacio.
Snapshot es un recubrimiento instantáneo de volumen/disco (EBS/ZFS/LVM). Necesitas snapshots de app-consistent (quiesce).
PITR (Point-in-Time Recovery) es un respaldo básico + registros (WAL/binlog) para retroceder a la hora exacta/LSN.
Objetos/Archivos/Imágenes: para tipos de datos específicos (imágenes VM, objetos S3, volcado DB).

5) Coherencia de los backups

Crash-consistent: como después de apagado repentino - adecuado para FS sin estado/registrable.
App-consistent: la aplicación «congela» las operaciones (fsfreeze/pre-post scripts) → integridad garantizada.
Consistencia BD: API de herramienta de respaldo (pgBackNat, XtraBackup), modos hot-backup, congelación de puntos de control.

6) Cifrado, claves y acceso

Encriptación in-nat e in-transit para todas las copias.
Claves en KMS/HSM, rotación de políticas (90/180 días), claves separadas por entorno.
Separación de responsabilidades: quién crea/elimina los backups ≠ quién los puede descifrar/leer.
No mantenga las claves de descifrado en el mismo dominio de confianza que las copias de destino.

7) Copias inmutables y protección contra ransomware

Object Lock/WORM (Compliance/Governance) con retoque y Legal Hold.
Air-gap: almacenamiento aislado/fuera de línea (cinta, nube/cuenta fuera de línea).
Políticas de eliminación «con activación diferida», MFA-Delete, cuenta separada para baquetas de respaldo, prohibición de acceso público.
Verificación en indicadores de malware/compromiso antes del montaje.

8) Frecuencia, horario y retiro

GFS (Grandfather-Father-Son): incrementales diurnos, full/diff semanales, full mensual con almacenamiento a largo plazo.
RPO dicta la frecuencia de incrementales y archiving WAL/binlog (por ejemplo, cada 5-15 minutos).
Almacenamiento: crítico - ≥ 35-90 días + mensual por 12-36 meses (requisitos legales).
Picos estacionales - puntos de control separados (antes de promociones/lanzamientos).

9) Modelos y escenarios DR

Active-Active: ambas regiones dan servicio al tráfico. Una RTO mínima, la captura de datos requiere una estricta política de conflictos.
Active-Passive (caliente/caliente): caliente - desplegado y sincronizado (minutos RTO), cálido - parcialmente listo (reloj RTO).
Cold: almacenamos copias y Terraform/Ansible/imágenes, elevamos bajo petición (RTO día +).
DRaaS: orquestación de proveedores de VM/redes/direcciones en otra zona.

10) Orquestación Feilover y prioridades de recuperación

La prioridad del lanzamiento: la red/VPN/DNS → los secretos/KMS → las bases/clústeres → los turnos/kesh → las aplicaciones → el perímetro/CDN → del analítico.
Automatización: scripts/acciones de Runbook, perfiles de Terraform/Ansible/Helm/ArgoCD para el entorno DR.
Datos: DB PITR → reindex/replica → caché warm → inicio de servicios con banderas de compatibilidad de circuitos.
DNS/GSLB: bajada de TTL por adelantado, escenarios de conmutación con validación.

11) Pruebas de recuperación (verificación de respaldo)

Pruebas de restauración programadas: muestreo de N% de backups, despliegue en «sandbox», comprobaciones automáticas de esquemas/invariantes.
DR-drill completo (game-day): desconexión de región/AZ, comprobación de RTO/RPO en tráfico en vivo (o sombras de tráfico).
Pruebas de integridad: directorios hash, sumas de comprobación, intento de lectura de todas las capas (full + chain).
Informe Dock: tiempo, pasos, anomalías, tamaño de la brecha de los objetivos, correcciones.

12) Prácticas para tecnologías básicas

Bases de datos

PostgreSQL: base backup + archivo WAL (PITR), herramientas pgBackNat/Barman; ranuras de replicación, control 'lsn'.
MySQL/MariaDB: Percona XtraBackup/Enterprise Backup, archiving binlog.
MongoDB: 'mongodump' para copia lógica + snapshot para conjuntos grandes; Oplog para PITR.
Redis: RDB/AOF para críticos (si Redis no es sólo caché), pero más a menudo es la reconstrucción lógica de origen + snapshot para accidentes.
Kafka/Pulsar: backup de metadatos (ZK/Kraft/BookKeeper), snapshots de discos, espejado de topics/logs.

Kubernetes

etcd snapshot + Velero para recursos/volúmenes (CSI snapshots).
Backup de secretos/PKI por separado (Vault snapshot).
Registro de imágenes separado: polisi de almacenamiento de artefactos (immutable tags).

Sistemas de archivos y VM

ZFS: 'zfs snapshot' + 'zfs amb | zstd | nat-recv' incrementos, verificando 'scrub'.
LVM/EBS snapshots con scripts pre/post (app-consistent).
Almacenamiento de objetos: versiones + Bloqueo de objetos.

13) Catalogación y control de versiones de backups

14) Observabilidad y métricas

Éxito de las tareas:% exitosas/inundadas, razones.
Tiempo de backup/recuperación, ancho de ventana.
RPO-Fáctico: Archivo de archivo de registro (WAL/binlog) p95.
Integridad: proporción de cadenas probadas, errores de conciliación de hash.
Costo: volumen de almacenamiento por clase, tasa de deduplicación/compresión.
Preparación DR: frecuencia y resultado de los ejercicios (pass/fail).

15) Políticas de acceso y cumplimiento

Cuentas/proyectos separados para repositorios de respaldo; Acceso NaC (no permitimos la eliminación/encriptación de las cuentas prod).
Registros de acceso/cambios (audit trail), alertas de eliminación masiva/cambios de retoque.
Cumplimiento de normas: GDPR (derecho de eliminación vs archivos), PCI DSS (cifrado, claves, segmentación), reguladores locales.

16) Anti-patrones

«Hay una réplica - significa que no se necesita un respaldo».
No immutable/air-gap: un error/malware borra todo.
Bacaps en la misma cuenta/región que el prod.
Nunca comprobar la recuperación (el respaldo está «muerto antes de la verificación»).
No hay catalogación y control de versiones → caos en un accidente.
Claves de cifrado compartidas para todos los entornos.
Snapshots sin modo app-consistent para BD.
La ventana de respaldo se cruza con los picos (afecta a los p99 y SLO).

17) Lista de verificación de implementación (0-60 días)

0-10 días

Inventario de sistemas/datos, clases de criticidad.
Exponer los objetivos de RPO/RTO por clase.
Habilitar full + incremental para Tier-0/1, archivo WAL/binlog.
Backups de distribución: región/cuenta separada + habilitar el cifrado KMS.

11-30 días

Configurar immutable (Object Lock/WORM) para copias críticas.
Introducir catalogación, etiquetas, informes; alertas para los fracasos y los magos de las revistas.
El primer DR-drill: restaurar un servicio separado de un respaldo en un entorno aislado.

31-60 días

Automatizar runbook: perfil DR de Terraform/Ansible/Helm.
Pruebas regulares de restore (semana/mes) + escenario trimestral completo de DR.
Optimizar el costo: deduplicación/compresión/ciclos de vida del almacenamiento de información.

18) Métricas de madurez

Pruebas de restauración: ≥ 1/ned para Tier-0 (selectivamente), ≥ 1/mes - escenario completo.
Immutable coverage для Tier-0/1 = 100%.
RPO-real p95 ≤ objetivo (por ejemplo, ≤ 15 min).
RTO-real en ejercicios DR ≤ objetivo (por ejemplo, ≤ 30 min).
Catálogo completo = 100% (cada respaldo se describe y verifica).
Incident-to-restore: tiempo desde la detección hasta el inicio de la recuperación.

19) Ejemplos (snippets)

PostgreSQL - PITR Policy (idea):

bash base backup once a day pgbackrest --stanza = prod --type = full backup archive WAL every 5 minutes pgbackrest --stanza = prod archive-push restore to time pgbackrest --stanza = prod restore --type = time --target =" 2025-11-03 14:00:00 + 02"

MySQL es un ciclo incremental:

bash xtrabackup --backup --target-dir=/backup/full-2025-11-01 xtrabackup --backup --incremental-basedir=/backup/full-2025-11-01 --target-dir=/backup/inc-2025-11-02 xtrabackup --prepare --apply-log-only --target-dir=/backup/full-2025-11-01 xtrabackup --prepare --target-dir=/backup/full-2025-11-01 --incremental-dir=/backup/inc-2025-11-02

Kubernetes - Velero (ideas de manifiestos):

yaml apiVersion: velero. io/v1 kind: Backup metadata: { name: prod-daily }
spec:
includedNamespaces: ["prod-"]
ttl: 720h storageLocation: s3-immutable

S3 Object Lock (ejemplo de política de ciclo de vida):

json
{
"Rules": [{
"ID": "prod-immutable",
"Status": "Enabled",
"NoncurrentVersionExpiration": { "NoncurrentDays": 365 }
}]
}

20) Comunicaciones y roles operativos

Incident Commander, Comms Lead, Ops Lead, DB Lead, Security.
Plantillas de mensajes para stakeholder/reguladores/usuarios.
Post-mortem con acciones: donde perdieron minutos, donde mejorar la automatización.

21) Conclusión

Un circuito robusto de backups y DR no es «hacer una copia», sino un ciclo: clasificación → objetivos RPO/RTO → copias multi-nivel e immutables → runbook automatizado 'y → restauraciones y ejercicios regulares. Adherirse al 3-2-1-1-0, separar la replicación de los backups, cifrar y aislar las claves, documentar y verificar. Entonces, incluso el «cisne negro» se convertirá en un proceso manejable con tiempos de inactividad predecibles y una pérdida mínima de datos.

Backups y recuperación de desaster