Ejecutar un simulacro de restauración PITR de PostgreSQL cada semana (este es nuestro runbook)

Una copia que nunca se ha restaurado es una esperanza, no una copia. Cada base de datos Postgres gestionada que operamos pasa por un simulacro semanal de point-in-time recovery (PITR), automatizado de extremo a extremo, con el resultado publicado en su informe de salud mensual.

Lo que realmente hace el simulacro

1. Elegir un timestamp aleatorio dentro de los últimos 7 días de retención WAL.
2. Aprovisionar una instancia sandbox en una clase de instancia más barata que producción.
3. Restaurar la última base backup en el sandbox.
4. Reproducir WAL hasta el timestamp elegido.
5. Ejecutar una sonda de integridad — diff de esquema contra producción, delta de row-count dentro de la tolerancia, un puñado de checks SQL de integridad.
6. Desmontar el sandbox. ~5 minutos de cómputo facturados. Reportar éxito o fallo.

Lo que pilla

Las cuatro cosas que este simulacro pilla y que las alertas «la copia ha corrido» no pillan:

• Copias que pasan silenciosamente de WAL+base a «solo snapshots» porque alguien cambió la política de retención
• Gaps WAL causados por fallos de archive_command que nadie notó porque la base de datos seguía corriendo
• Drift de permisos que deja que las copias se hagan pero bloquea al rol de restauración leerlas
• Rotación de claves de cifrado que dejó inservibles los snapshots más antiguos

Lo que no automatizamos

No automatizamos la declaración del desastre. El runbook exige explícitamente que un humano decida vamos a hacer una restauración real, no el simulacro. Esa barrera nos ha salvado más de una vez de «la automatización se desboca y restaura producción a ayer».

El runbook completo en Medium contiene el Terraform que usamos para levantar el sandbox, el Bash que compara esquemas, y las reglas de alerta que escalan cuando el simulacro falla dos veces seguidas.