Estrategias de Backup Físico, PITR y Replicación
En la administración física de bases de datos, garantizar la disponibilidad continua y la recuperación inmediata ante desastres es la responsabilidad más crítica.
Un fallo de hardware, una corrupción de disco o un comando destructivo accidental (DROP DATABASE) exigen disponer de estrategias formales de copias de seguridad físicas, archivado de logs transaccionales y replicación en tiempo real.
1. Métricas de Continuidad: RPO y RTO #
Antes de diseñar la estrategia de backups, se deben acordar dos métricas con el negocio:
1Momento del Desastre 💥 2─────────────┼────────────────────────► Tiempo 3◄─── RPO ────►◄───────── RTO ─────────► 4Pérdida de datos Tiempo de caída 5tolerable hasta restaurar
- RPO (Recovery Point Objective): Cantidad máxima de datos que la organización puede permitirse perder (medida en tiempo). Si el RPO es 0, no se puede perder ni una sola transacción.
- RTO (Recovery Time Objective): Tiempo máximo permitido para que el sistema vuelva a estar operativo tras un desastre.
2. Backups Lógicos vs. Backups Físicos #
| Característica | Backup Lógico (pg_dump, mysqldump) | Backup Físico (pg_basebackup, Snapshots) |
|---|---|---|
| Contenido | Sentencias SQL de creación e inserción de datos | Copia binaria exacta de los bloques de disco y tablas |
| Velocidad de copia | Lenta en bases de datos grandes (lee fila por fila) | Muy rápida (copia secuencial de bloques de disco) |
| Velocidad de restauración | Lenta (debe reejecutar SQL y reconstruir índices) | Instantánea (sustitución directa del directorio de datos) |
| Portabilidad | Alta (fácil de migrar entre versiones o motores) | Baja (requiere la misma versión y arquitectura de SGBD) |
| Tamaño idóneo | Bases de datos pequeñas y medianas (< 100 GB) | Bases de datos grandes y críticas (> 100 GB a Terabytes) |
3. Recuperación a un Punto en el Tiempo (Point-In-Time Recovery / PITR) #
La técnica PITR permite restaurar la base de datos al estado exacto que tenía en cualquier segundo del pasado (por ejemplo, exactamente a las 14:32:15, un segundo antes de que un desarrollador ejecutara un DROP TABLE por error).
¿Cómo funciona el proceso PITR? #
- Se restaura el backup físico base más reciente (ej. el volcado de las 00:00 h).
- Se configuran los ficheros de registro transaccional (WAL en PostgreSQL o Binlog en MySQL).
- El motor reproduce (Replay) todas las transacciones confirmadas una tras otra y se detiene automáticamente en la marca de tiempo indicada:
1-- Configuración de PITR en PostgreSQL (postgresql.conf / recovery.signal) 2restore_command = 'cp /mnt/wal_archive/%f %p' 3recovery_target_time = '2026-09-01 14:32:15 UTC' 4recovery_target_action = 'promote'
4. Replicación Física en Streaming #
Para lograr alta disponibilidad y balanceo de lecturas, los servidores de base de datos se configuran en clústeres de replicación:
1┌──────────────────────┐ Streaming de WAL / Binlogs ┌──────────────────────┐ 2│ NODO PRIMARIO (RW) │──────────────────────────────────────►│ RÉPLICA STANDBY (RO)│ 3│ Lectura y Escritura │ │ Solo Lectura │ 4└──────────────────────┘ └──────────────────────┘
- Replicación Asíncrona: El primario confirma el
COMMITal cliente sin esperar a que la réplica reciba los datos (máximo rendimiento, riesgo mínimo de retraso en réplicas). - Replicación Síncrona: El primario espera a que al menos una réplica confirme haber escrito el log en disco antes de devolver éxito al cliente (RPO = 0 garantizado, mayor latencia en escrituras).
5. Comandos de Utilidad Multi-Motor #
Resumen del tema
Conceptos clave #
- RPO / RTO: objetivos de pérdida máxima de datos (RPO) y tiempo de restauración tolerable (RTO).
- Backups físicos: copias binarias directas de los ficheros de datos en disco, indispensables para bases de datos de gran volumen y recuperaciones ultra-rápidas.
- Point-In-Time Recovery (PITR): combinación de backup físico base con la reproducción secuencial de logs transaccionales (WAL/Binlogs) hasta una marca temporal concreta.
- Streaming Replication: transmisión continua de registros transaccionales a nodos réplica secundarios para alta disponibilidad y reparto de consultas de lectura.
Qué debes recordar #
Un backup sin archivado continuo de logs WAL/Binlogs solo permite recuperar el estado en el momento del backup; para un RPO cercano a cero es imprescindible habilitar PITR y replicación en streaming.