panels-origin/db/backups/restore-drill-checklist.md
Cursor Agent d36c287a82
db/infra: ETL de datos, backups y limpieza de despliegue (fase 5-7)
Fase 5 (migracion de datos):
- api/scripts/migrate-sqlite-to-postgres.ts: ETL unico SQLite -> Postgres.
  Pre-flight (CURP/RFC duplicados case-insensitive, FKs huerfanas,
  tenant_id invalido, fechas mal formateadas) -> carga por base/esquema
  con credenciales _owner (setval de secuencias, OVERRIDING SYSTEM VALUE,
  ON CONFLICT DO NOTHING idempotente) -> verificacion de conteos y sumas
  de dinero con tolerancia. Probado end-to-end contra un dataset SQLite
  legacy sintetico y un Postgres limpio (solo schema+catalogos, sin
  contexto dev): 100% de las filas migradas, sumas de dinero exactas,
  snapshot de uploaded_by/created_by resuelto correctamente.
- db/RUNBOOK-corte.md: checklist go/no-go para el corte por ambiente.
- Fix de bug real encontrado al probar: sin --context-filter explicito,
  Liquibase corre TAMBIEN los changesets context=dev (comportamiento por
  defecto, no "modo seguro") -- documentado en db/README.md con el
  ejemplo correcto (--context-filter='!dev' para staging/produccion).

Fase 5b: patron de compensacion para createTenant ya resuelto en el
rewrite de saas.ts (fase 3/4).

Fase 6 (backups): db/backups/ con plantillas pgBackRest por base,
politica de retencion, nota de persistencia minima de Redis (RDB, sin
retencion de negocio), checklist de simulacro de restauracion mensual,
y la validacion pendiente de si Coolify permite WAL archiving antes de
comprometerse a PITR real.

Fase 7 (limpieza y CI):
- Dockerfile.api simplificado (sin JRE/Liquibase/FFI). Dockerfile.migrate
  y Dockerfile.provision nuevos, de un solo uso, para el paso explicito
  de deploy (nunca sirven trafico).
- docker-compose.yml: postgres+redis+provision+migrate para dev local
  end-to-end; api ya no arranca hasta que migrate termina bien.
- docs/coolify.md y .env.example actualizados al modelo de 2 bases +
  Redis + Contabo.
- api/schema.sql eliminado (desincronizado, competia con Liquibase como
  fuente de verdad).
- .github/workflows/ci.yml: Postgres+Redis de servicio, aprovisiona
  roles/ACLs, dry-run de Liquibase (updateSQL) antes de aplicar,
  verify-isolation.sh, deno check + deno test, build de los dos frontends.

Co-authored-by: alberto.martinez <alberto.martinez@mrdev.mx>
2026-09-02 21:05:07 +00:00

1.9 KiB

Simulacro de restauración (mensual, obligatorio)

Un backup que nunca se probó restaurar no es un backup. Correr esto en un ambiente descartable (nunca contra staging/producción reales).

Checklist

  • Levantar un Postgres nuevo y vacío (contenedor descartable).
  • Restaurar el backup más reciente de panels_platform: - pgBackRest: pgbackrest --stanza=panels_platform restore - o pg_restore si es dump lógico.
  • Restaurar el backup más reciente de panels_product (mismo método).
  • Correr db/provision/verify-isolation.sh contra el ambiente restaurado -- confirma que roles/RLS/permisos sobrevivieron el restore intactos, no solo los datos.
  • Spot-check de datos: comparar conteos de filas y 2-3 registros conocidos contra lo que se espera (usar el mismo enfoque que verifyCounts()/verifyMoney() del ETL, ver api/scripts/migrate-sqlite-to-postgres.ts como referencia de qué comparar).
  • Si hay WAL archiving: probar un restore a un punto en el tiempo específico (no solo "el último backup"), confirmar que aterriza en el estado esperado para ese instante.
  • Archivos (Contabo): confirmar que al menos una descarga de documento cifrado conocido sigue descifrando correctamente después del restore (prueba de que la clave DOCS_KEY y el bucket siguen consistentes).
  • Documentar cuánto tardó el restore de punta a punta -- es el RTO real, no el teórico.
  • Destruir el ambiente descartable al terminar.

Cuándo escalar

Si cualquier paso falla (restore no completa, RLS no aplica, datos no cuadran, documento no descifra), no esperar al siguiente simulacro -- es una señal de que el backup en producción probablemente tampoco sirve. Tratarlo como incidente, no como hallazgo de rutina.