Skip to content
Usuario

Backup y restore

No se encontro sistema de backups implementado en los repos. Esto es requisito de infraestructura antes de produccion.

ActivoRespaldar
MySQLSchema, datos, procedimientos/funciones si existen, indices, usuarios segun politica.
StorageBuckets de firmas, fotos, rayos X, perfiles y configuraciones si se usan.
Configuracion infraDNS, proxy, TLS, jobs, variables no secretas.
Secret metadataNombres/versiones de secretos, no valores.
Docs/runbooksVersion del manual y reportes operativos.
  • En el mismo disco unico de la DB.
  • En repos Git.
  • En equipos personales.
  • En buckets publicos.
  • En carpetas compartidas sin cifrado.
  • En herramientas de chat.
ControlRecomendacion
Frecuencia fullDiario.
Incremental/binlogSegun RPO, idealmente continuo o por hora.
CifradoEn reposo y en transito.
Retencion7 diarios, 4 semanales, 12 mensuales como punto inicial.
Restore testMensual y antes de produccion.
SeparacionBackups fuera del host principal.
AccesoMFA, minimo privilegio, auditoria.
  1. Crear ambiente aislado.
  2. Restaurar backup DB.
  3. Restaurar storage necesario.
  4. Configurar backend con secretos de prueba, no productivos.
  5. Arrancar backend.
  6. Ejecutar smoke tests.
  7. Verificar conteos y consistencia.
  8. Confirmar que no hay fixtures QA activos.
  9. Documentar tiempo de restore y errores.

Restore a un punto anterior puede reactivar sesiones o refresh tokens que ya fueron cerrados. Tras restore productivo:

  • Considerar cierre global de sesiones.
  • Revocar refresh tokens si hay duda.
  • Forzar re-login.
  • Rotar secretos si el backup pudo exponerse.
  • Monitorear 401/refresh failures.
  • Backend conecta a DB restaurada.
  • GET /api/auth/session responde.
  • Login QA funciona.
  • Logout limpia cookies.
  • Super Admin close invalida sesion.
  • Reset password invalidation probado si SMTP esta disponible.
  • CORS/CSRF siguen configurados con dominios reales.
  • Backups nuevos vuelven a correr despues del restore.