¿Cómo es realmente una buena estrategia de backup y recuperación ante desastres? (RPO/RTO, recuperación a un punto en el tiempo)

#Empieza por la pregunta de negocio, no por la herramienta

Antes de elegir una herramienta de backup, a un entrevistador le interesa escuchar que partes de dos números que el negocio debe definir:

• RPO (Recovery Point Objective / Objetivo de Punto de Recuperación) — ¿cuántos datos podemos permitirnos perder, medido en tiempo? Si el RPO es de 5 minutos, un backup nocturno no es una estrategia de backup, es una carta de renuncia.
• RTO (Recovery Time Objective / Objetivo de Tiempo de Recuperación) — ¿cuánto tiempo puede estar caído el sistema mientras se recupera? Un RTO de 15 minutos descarta de plano "restaurar un dump de 2TB desde S3 y reproducir los logs".

Toda decisión técnica —frecuencia de backup, topología de replicación, región de standby— se deriva de esos dos números. Una respuesta senior los nombra explícitamente en lugar de saltar directo a "usamos snapshots".

#La taxonomía de backups

• Backup completo (full) — una copia completa de la base de datos en un momento dado (pg_dump, mysqldump, un snapshot a nivel de almacenamiento). Simple de restaurar, costoso de hacer con frecuencia en una base grande.
• Backup incremental / diferencial — captura solo lo que cambió desde el último backup completo (o el último incremental). Más barato de tomar, más pasos para reconstruir en la restauración.
• Backup físico (a nivel de bloque) — copia los archivos de datos o bloques de disco reales (pg_basebackup, snapshots de EBS/LVM, Percona XtraBackup). Rápido de tomar y restaurar, pero atado a la misma versión y arquitectura del motor.
• Backup lógico — un dump de sentencias SQL o un formato de datos portable. Más lento en datasets grandes, pero portable entre versiones e incluso entre motores, y permite restaurar una sola tabla.
• Archivado continuo (WAL/binlog shipping) — la pieza que convierte un "backup" en "recuperación a un punto en el tiempo". La base de datos envía continuamente su write-ahead log (WAL de Postgres?) o su binary log (binlog de MySQL) a almacenamiento durable. Combinado con un backup base periódico, puedes reproducir los logs hasta cualquier marca de tiempo.

#Recuperación a un punto en el tiempo (PITR)

PITR es la funcionalidad que responde a "alguien ejecutó un UPDATE sin WHERE a las 14:32 — regrésanos a las 14:31". La mecánica:

1. Restaurar el backup completo/base más reciente tomado antes del momento objetivo.
2. Reproducir los registros de WAL/binlog archivados desde la marca de tiempo de ese backup hasta (sin incluir) la transacción problemática.
3. Promover la instancia restaurada una vez validada.

Por esto el archivado continuo de logs importa incluso si también haces backups completos nocturnos: el backup completo te da un punto de partida rápido, los logs te dan granularidad de menos de un segundo. Sin el envío de logs, tu punto de recuperación nunca será más reciente que tu último backup completo, sin importar cuán disciplinado sea tu calendario de backups.

#Dónde vive realmente el backup

Un backup guardado en el mismo host, el mismo disco o la misma zona de disponibilidad que el primario no es un backup de recuperación ante desastres — te protege de un DROP TABLE, no de la falla de un rack, una caída de zona de disponibilidad o un ransomware que llega a todo lo que las credenciales de la app pueden alcanzar. Una estrategia real tiene capas:

• Almacenamiento de objetos durable en la misma región (S3/GCS) con versionado y, idealmente, object lock/inmutabilidad durante una ventana de retención definida (protege también contra un atacante o un bug que borre tus propios backups).
• Replicación entre regiones de ese almacenamiento de backups, dimensionada según tu RTO.
• Para los niveles más críticos, un standby tibio o caliente en una segunda región que pueda promoverse, no solo un archivo de backup esperando a ser restaurado.

#Failover: promover un standby vs. restaurar desde backup

Son dos herramientas distintas para dos clases de falla distintas:

• Promover un standby (una réplica se convierte en primario) es rápido — segundos a un par de minutos— y es la respuesta a "el primario murió" o "la zona del primario desapareció". No te protege de corrupción lógica, porque la réplica replicó fielmente también el DELETE erróneo.
• Restaurar + PITR es la respuesta a "los datos mismos están mal" — un bug de la aplicación escribió basura, una migración salió mal, un actor malicioso borró filas. Es más lento por naturaleza, porque estás reconstruyendo el estado desde un snapshot anterior más una reproducción de logs.

Un plan de DR maduro tiene ambos, y sabe cuál corresponde a cada incidente.

#La parte que casi todos se saltan: probar la restauración

Una respuesta de entrevista que destaca dice esto explícitamente: un backup no probado es una hipótesis, no un backup. Corrupción en el archivo de backup, un desajuste de esquema, una llave de cifrado expirada, IOPS insuficientes en el destino de restauración — todo esto es invisible hasta que intentas restaurar, y por definición lo descubres en el peor momento posible si el primer intento de restauración es el incidente real. Los equipos maduros ejecutan simulacros de restauración programados (mensuales o trimestrales), miden el RTO real logrado y lo comparan contra el objetivo — y tratan "nunca hemos probado esto" como un incidente de producción esperando a ocurrir, no como una casilla por marcar.

🧠 Check your understanding
0/3 · 0/3 answered
1. Un equipo hace un backup completo cada noche a las 2 AM y no tiene archivado de WAL/binlog. ¿Cuál es su RPO efectivo?
Hasta 24 horas, ya que el último backup completo es el único punto de recuperaciónExactamente 15 minutos, el estándar de la industriaDepende únicamente del RTO, no de la frecuencia de backupCasi cero, porque los backups corren a diario
2. ¿Por qué promover una réplica a primario NO sustituye a la recuperación a un punto en el tiempo?
Las réplicas no pueden promoverse sin downtimeUna réplica aplica fielmente los mismos errores lógicos (DELETE/UPDATE erróneos) que el primarioLas réplicas usan un esquema distinto al del primarioPromover siempre tarda más que restaurar
3. ¿Cuál es la razón principal para ejecutar simulacros de restauración programados en lugar de confiar en que los backups se completaron con éxito?
Los simulacros reducen el costo de almacenamiento de los backupsLos simulacros son obligatorios en todos los marcos de cumplimiento sin excepciónQue un job de backup termine con éxito no garantiza que el archivo sea restaurable, y las fallas suelen aparecer solo al restaurarLos simulacros de restauración eliminan la necesidad de replicación entre regiones