mirror of
https://origin.cursor.com/mrdevmx/panels.git
synced 2026-10-09 16:13:17 +00:00
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>
37 lines
1.9 KiB
Markdown
37 lines
1.9 KiB
Markdown
# 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`](../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`](../../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.
|