Estrategias de respaldo y replicación

Resumen breve

Una estrategia de datos sólida se basa en tres pilares: respaldo, replicación, recuperación. La réplica reduce el RTO (tiempo de recuperación), el respaldo garantiza RPO (pérdida de datos) y protege contra errores lógicos/cifradores. Principios básicos: 3-2-1-1-0 (3 copias, 2 tipos de medios, 1 offsite, 1 inmutable, 0 errores de validación), pruebas regulares de DR e inmutabilidad de kits críticos.

Términos y objetivos

RPO - cuántos datos se pueden perder (por ejemplo, ≤ 5 minutos).
RTO - cuánto tiempo se puede recuperar (por ejemplo, ≤ 15 minutos).
PITR (Point-in-Time Recovery) es una recuperación «en el momento X» con una réplica de registros.
SLO Data es un contrato de nivel de servicio para RPO/RTO y el éxito de las tareas de respaldo.

Ejemplo de matriz:

Clase de datos	RPO	RTO	Notas
Transacciones/billetera	≤ de 1 a 5 minas	≤ 5-15 minas	Registros + réplica sincrónica del núcleo
Presentación de informes/PII	≤ 1 h	≤ 1 h	WORM/immutability, archivos
Registros/eventos crudos	≤ 24 h	≤ 4 h	Objeto, lifecycle

Modelos de tolerancia a fallas y replicación

Opciones de topologías

Active-Passive (caliente/cálido/frío): más fácil, predecible Feilover.
Active-Active: alta disponibilidad, pero más difícil conflicto-resolve y consistencia.
Multi-Zone/Región/Nube: balance de retrasos y valor de egresos.

Sincron vs asinchron

Sincrón: RPO≈0, por encima de latencia, límite de distancia.
Asinchron: cerca de cero RTO en RPO pequeño (minutos), soporta regiones/nubes.
Híbrido: sincrono dentro de la zona, asíncrono en una región remota.

Réplica ≠ retroceso

La réplica lleva errores/eliminaciones después del origen. Backup - Copia off-path con versificación, verificación y aislamiento.

Política 3-2-1-1-0 e inmutabilidad

3 copias (prod + local de respaldo + offsite).
2 tipos de medios (bloque/NAS/objeto/cinta).
1 offsite (otro sitio/nube/cinta).
1 copia inmutable (WORM: Object Lock, immutable snapshots/cinta).
0 errores: comprobación regular de la integración (checksum/verify/restore-test).

Práctica:

Habilite la versificación y el bloqueo de objetos (Compliance/Governance) para un objeto con backups críticos.
Para NAS/unidades: snapshots immutables con retoque y prohibición de eliminación antes de la fecha límite.

Tipos de respaldo y horarios

Full es una copia completa.
Incremental - sólo cambios desde el pasado del respaldo.
Differential: cambios desde el último completo.
Forever-incremental con el plan GFS (Grandfather-Father-Son): incrementos diurnos, semanales y mensuales «completos sintéticos».

Recomendación (ejemplo):

Prod BD: full (o full sintético) diario, incrementos/registros cada 5-15 minutos (PITR).
Servidores de archivos: full semanal, incremental diario, archivos mensuales.
Objeto: lifecycle + versiones; frío - en la clase de archivo de almacenamiento/cinta.

Aplicaciones y DAB: prácticas de PITR

PostgreSQL

Habilitar copia de seguridad WAL y base; PITR a través de 'restore _ command'.
Herramientas: 'pgBackNat', 'wal-g' (objeto), 'pg _ basebackup' para los completos.
Separar volúmenes: datos y WAL; escribir WAL en NVMe rápido con PLP.

MySQL/MariaDB

Registro binario para PITR, completo a través de 'Percona XtraBackup' (backup caliente).
Replicación GTID; para DR - asinchron a la región/nube.

MongoDB

Oplog para PITR; snapshots a nivel storage + 'mongodump' para copias lógicas.
Probar la consistencia de la réplica antes del respaldo.

Redis/Caché

No considerar un respaldo: mantener RDB/AOF + offsite; restaurar como warm-cache o desde una fuente de verdad.

Kubernetes y contenedores

etcd del clúster es un objetivo crítico separado (snapshots frecuentes, offsite).
Velero: backup de manifiestos/recursos + snapshots CSI/PV; almacenamiento en una baqueta compatible con S3 (con Object Lock).
Stateful-strikes: app-consistent snapshots (pre/post hooks), de lo contrario - crash-consistent.
Versionar artefactos de objetos (modelo/medios) - a nivel de baquetas.

Virtualización y servidores de archivos

Snapshots VM: usar CBT (Changed Block Tracking), almacenar offsite, hacer periódicamente guest-aware quiesce (VSS para Windows).
Servidores de archivos (NAS): snapshots + réplica y pruebas de restauración de directorio regulares (muestreo de archivos).

Seguridad

Cifrado en reposo (LUKS/ZFS/cloud KMS/Vault) y en transmisión (TLS/mTLS).
Administración de claves: roles individuales, control dual, rotación, almacenamiento de claves maestras fuera de línea.
Aislamiento: cuentas de software de respaldo sin derechos para eliminar copias inmutables; redes/VLAN separadas.
Resistencia a ransomware: immutable, air-gap (cintas/cuenta aislada/labs).
Auditoría: registro de operaciones del sistema de respaldo, alertas de eliminación/reducción de retoque.

Planificación de ventanas y ancho de banda

Backup window vs carga: trottling I/O/red, deduplicación, compresión.
Red: incrementos cada N minutos, canales individuales/VPN, réplica por la noche o constantemente con QoS.
Cambiar el seguimiento de bloques/CDC para reducir el tráfico.
Bases grandes: hilos paralelos/streaming, multipart multicanal en el objeto.

Monitoreo, métricas y SLO

T-métricas:

Éxito de las tareas de backup/replicación (%), duración, velocidad, registro (WAL/binlog/oplog).
Espacio de almacenamiento de respaldo, factor de dedoup, otros costos.
Tiempo y éxito de las pruebas de recuperación.

SLO (ejemplo):

Éxito de los backups ≥ 99. 9 %/30 días.
La RPO se cumple ≥ el 99% del tiempo (registro de registro ≤ objetivo).
RTO (prueba de restauración) ≤ 15 min para la cartera, ≤ 1 h para reportar.
DR-drill mensual: 100% de los escenarios reglamentarios completados.

Alertas:

Backup omitido/fallido, log PITR> del umbral, caída del grado de la deduplicación, falta de espacio, cambio de la política de la retransmisión, ninguna prueba-restore fresca.

Ejercicios de DR y verificación de recuperación

Tabla (table-top): coordinación de roles, contactos, comunicaciones.
Técnico: recuperación en sandbox, medición de RTO, comparación de cantidades/datos de control.
Black-start: recuperación completa a «hierro desnudo/cluster limpio».
Catálogos de datos: pasos de recuperación predefinidos (runbooks) para cada clase de sistema.
Automatización: restauración periódica «canaria» y conciliación de cantidades de control.

Plantillas prácticas

1) PostgreSQL (pgBackNat + archivo WAL en el objeto)

ini
[global]
repo1-type=s3 repo1-path=/pgbackups repo1-s3-endpoint=minio. local:9000 repo1-s3-bucket=pg-wal repo1-s3-key=ACCESSKEY repo1-s3-key-secret=SECRET repo1-retention-full=8 start-fast=y compress-type=zst

2) wal-g (ejemplo ENV)

bash export WALG_S3_PREFIX=s3://pg-wal/prod export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export WALG_COMPRESSION_METHOD=zstd

3) Velero (K8s - objeto + inmutabilidad baqueta)

yaml apiVersion: velero. io/v1 kind: BackupStorageLocation metadata: { name: default, namespace: velero }
spec:
provider: aws objectStorage:
bucket: k8s-backups config:
s3Url: https://minio. example s3ForcePathStyle: "true"
publicUrl: https://minio. example

4) Política de bloqueo de objetos (ejemplo 'mc')

bash mc version enable my/backups mc retention set --default COMPLIANCE 365d my/backups

5) Ejemplo de programación GFS (concepto)

Diario: incrementos cada 15 min (revistas), día sintético completo.
Semanal: uno «completo» (sintético), almacenar 8 semanas.
Monthly: completo, almacenar 12-24 meses (archivo/cinta).

Lista de comprobación de implementación

Clases de datos definidas, propietarios, RPO/RTO/SLO.
Se seleccionaron los modelos de replicación (sync/async) y topología (AZ/Region/Cloud).
Backups configurados: full/incremental/PITR, horarios, catálogos.
Se incluyen la inmutabilidad (WORM/Object Lock/immutable snapshots) y el offsite/air-gap.
Cifrado y KMS/Vault, funciones separadas y rotación de claves.
Monitoreo: Éxito de las tareas, Magazine Magazine, Place, Test Restore; alertas.
Runbooks de recuperación y Feilover; contactos, escaladas, patrones de comunicación.
Ejercicios mensuales de RD + informe, corrección de planes.
Presupuesto y FinOps: costo de almacenamiento/egress, proyecto de archivo/tirada.

Errores típicos

«Hay una réplica - no se necesita un respaldo»: las eliminaciones lógicas y los ransomware saldrán para la réplica.
No hay pruebas de recuperación - el respaldo existe «teóricamente».
La falta de inmutabilidad y offsite es un único punto de riesgo.
La misma cuenta/llaves para la prueba y los backups - compromiso = pérdida de todo.
Ventanas de respaldo demasiado largas → conflicto con los picos; No trottling y QoS.
PITR sin control de registro.
Ignorar los snapshots de app-consistent son volúmenes «sucios» recuperables.

Características específicas para iGaming/Fintech

Billetera/núcleo de pago: RPO ≤ 1-5 min, RTO ≤ 15 min; registros (WAL/binlog) en un objeto con WORM; sincronía en zona + región asíncrona.
Informes/regulaciones: almacenamiento inmutable, retén prolongado (años), integridad verificable, procedimientos claros para la emisión de datos a los reguladores.
Registros/eventos crudos/antifraude: almacenamiento de larga vida barato (objeto) + lifecycle; índices y escaparates por separado.
Piques (partidos/torneos): ventanas de respaldo fuera de los picos, throttling; Planes de DR para el período de eventos; restore canario antes de las promociones.

Resultado

La protección de datos es una disciplina arquitectónica: 3-2-1-1-0, versificación e inmutabilidad, RPO/RTO como SLO, ejercicios regulares de DR y verificación de recuperación «de hecho». Combine la replicación para el aptime y los failover rápidos con los backups para errores lógicos y compromisarios. Automatice, mida, documente - y siempre tendrá una ruta de trabajo hacia atrás, incluso en el día más malo.