Restoredrill: verifica que tus backups de Postgres sí restauran

Por qué un backup sin prueba de restore es solo una esperanza

En el mundo de las startups, "tenemos backups" es una frase que se repite en cada pitch y cada status interno. El problema es que, según el repositorio de la herramienta Restoredrill publicado en GitHub, "los backups no probados no son backups" — y aun así, casi nadie verifica que se puedan restaurar. La razón suele ser la misma: no hay un entorno seguro donde hacerlo y el tiempo siempre apremia.

Restoredrill es un proyecto open source en Go, en su versión v0.1.0, que ataca exactamente ese hueco. Toma el backup más reciente, lo restaura en un contenedor efímero de PostgreSQL, ejecuta validaciones definidas por el usuario y emite un reporte JSON con la duración de la restauración. Todo sin tocar producción.

Qué hace Restoredrill, en concreto

El flujo está pensado para que sea un hábito de un solo comando, no un proyecto de infraestructura:

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Genera el dump con pg_dump -Fc -d "$DATABASE_URL" -f backup.dump, ya sea desde Supabase, RDS o un Postgres local.
Copia un YAML de ejemplo junto al archivo, apuntando la fuente al backup.
Ejecuta la prueba: restoredrill --config quickstart.yml --trigger manual.

El resultado es una línea como: restoredrill: PASS, restore took 4.2s, 1/1 checks passed, report: restoredrill-report.json. En unos diez minutos tienes en tu laptop un JSON firmado con timestamp que demuestra que un restore real ocurrió.

Las verificaciones en capas que sí detecta fallos silenciosos

El proyecto divide los chequeos en niveles, todos con política fail-closed: si una verificación no puede ejecutarse, cuenta como fallo, no como salto. Los tiers, según la documentación oficial del repositorio, son:

Prechecks: que el archivo tenga tamaño mínimo razonable, que su cabecera sea legible y que la edad del backup respete el objetivo RPO (punto de recuperación). Este control detecta el caso clásico: un cron murió en silencio y dejó el mismo archivo viejo en S3.
Estructurales: que la restauración haya finalizado, que existan las tablas esperadas y que las secuencias estén alineadas con el máximo valor de su columna. Una secuencia desfasada solo aparece en el primer INSERT después de un desastre real — Restoredrill lo detecta ahora.
Read-path: conteos de filas, frescura de datos y cualquier aserción SQL que escribas. Una restauración puede salir con código 0 y estar mintiendo hasta que alguien lea los datos. La propia herramienta documenta un incidente real en el que esto ocurrió.
Evidencia RTO: cuánto tardó realmente el restore, comparado contra un objetivo si lo configuraste.
Sanity de entorno: el Postgres efímero debe arrancar y aceptar conexiones, lo que también prueba que tu infraestructura de recuperación tiene margen para trabajar.

El reporte JSON es el producto, no la automatización

El autor de Restoredrill señala en el README que automatizar la restauración es la parte fácil; lograr un formato de reporte que un auditor acepte al primer intento costó "tres reescrituras y meses de idas y vueltas con un auditor real". Por eso cada campo del JSON está siempre presente — incluso cuando no aplica — para que copiar y pegar a una hoja de cálculo no rompa el layout.

Los campos clave del reporte incluyen: triggered_by, backup_resolved_key (el archivo realmente probado, no la fuente configurada), backup_candidates_considered (todos los objetos del prefijo S3 evaluados y por qué se descartaron), backup_age_seconds con rpo_met, restore_duration_seconds con rto_met, validation_errors por separado y notify_errors para fallos de entrega en Slack o webhooks. Todos los timestamps van como literal YYYY-MM-DD HH:MM:SS UTC — no epoch ni RFC3339 — porque la mayoría de los flujos de auditoría terminan en copy-paste.

Un detalle clave contra ataques silenciosos: si la fuente es un prefijo de S3, Restoredrill verifica que cada candidato tenga la firma PGDMP antes de elegirlo. Un archivo de checksum subido después del backup real no puede "ganar" solo por ser más nuevo.

Qué implica para tu startup si vendes a clientes enterprise

Cuando un cliente enterprise te pide SOC 2 o ISO 27001, los auditores no aceptan políticas en papel: piden evidencia ejecutable. Según un análisis publicado por Infosecurity Magazine, el control de "Testing restore" en SOC 2 mapea al criterio Availability (A1.3) y, en ISO 27001, a A.8.13 (Information backup) combinado con A.5.30 (ICT readiness for business continuity). El mismo artículo lista explícitamente "logs from your backup tool, including test restore ones" entre la evidencia que los auditores suelen pedir.

En otras palabras: un documento de política que dice "probamos trimestralmente" puede haberse redactado la semana pasada sin que se haya ejecutado nada en un año. Un reporte timestampado, firmado por una pipeline, es mucho más difícil de falsificar — y ese es exactamente el formato que Restoredrill produce.

Cómo encaja con el ecosistema existente

El propio README nombra competidores con honestidad poco habitual:

Databasus es una plataforma self-hosted con interfaz web para backups de Postgres, MySQL, MariaDB y MongoDB, con verificación de restore ya integrada. Es ideal si quieres un único dashboard para múltiples motores. Una comparativa en dev.to confirma que Databasus está orientada a desarrolladores y equipos con necesidad de workspaces, RBAC y notificaciones nativas en Slack, Teams o Telegram.
BackupDrill hace algo similar, pero específicamente para Supabase, incluyendo archivos de Storage.

Restoredrill no intenta reemplazar a ninguno. Es una pieza CI-native, de un solo propósito, diseñada para producir evidencia en un formato que un auditor acepte sin traducirlo. Si ya tienes una herramienta de backup y solo necesitas probar que restaura, con la cadencia que tu política exige, en formato apto para auditoría, está construida para ese hueco exacto.

Qué significa esto para tu startup

Aunque no estés cerca de una auditoría, la disciplina de probar restores tiene retorno inmediato en confiabilidad operativa. Tres acciones concretas que puedes tomar esta semana:

Audita tu política de backups hoy mismo. Abre tu última política de DR y marca qué dice sobre frecuencia de pruebas de restore. Si dice "trimestral" y no tienes un artefacto firmado que lo respalde, ese es tu hallazgo.
Prueba un restore manual esta semana. Sin CI, sin S3, en tu laptop. El flujo de pg_dump -Fc + el YAML de ejemplo de Restoredrill toma unos diez minutos y te da el primer reporte JSON honesto. Si eso falla, ya tienes información valiosa antes de que falle en producción.
Conecta el resultado a donde ya miras. Restoredrill puede escribir métricas de Prometheus con output.prometheus_textfile para alertar sobre la antigüedad del último drill. Si tu drill deja de correr silenciosamente, lo verás antes de que un cliente te lo diga.

Limitaciones que conviene tener en mente

La documentación oficial es explícita sobre lo que la herramienta no hace todavía:

El modelo de contenedor efímero asume que tu base cabe cómoda en el runner. Bases multi-terabyte requieren infraestructura dedicada.
La verificación a nivel de pg_dump no ejercita PITR ni WAL replay. Soporte para pgBackRest está en el roadmap.
El precheck de integridad del archivo solo funciona con pg_dump_custom. Los dumps SQL planos no tienen cabecera de tabla de contenidos, así que su corrupción se detecta más tarde, en el momento del restore.
El autor no cita números de cláusula específicos de SOC 2 o ISO 27001 a propósito: una cita mal de un control puede ser peor que no citarlo. Lo que sí garantiza el reporte es que cada control subyacente — documented, provable recovery testing on whatever cadence your policy sets — tenga evidencia.

En el roadmap aparecen PITR con pgBackRest, fuentes en GCS, soporte para MySQL, checks diferenciales entre lo restaurado y producción, y un modo scheduled. Vale la pena seguir el repositorio si operas Postgres en producción.