Toda la documentación pasa de voseo a tratamiento de usted, incluidos los diagramas y los textos de la interfaz. Los prompts de ambos asistentes lo piden explícitamente, para que las respuestas generadas también lo respeten. El panel de LIA en la página de documentación adopta el diseño del dashboard del turnero: mismo botón circular, mismo panel deslizante con encabezado en degradado y logo LIA, mismos chips de atajo, burbujas y campo de entrada. Los atajos se arman con los documentos que ese usuario puede ver. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
3.9 KiB
Respaldos y recuperación
Qué hay que respaldar, y qué se pierde si no está.
Las tres cosas a respaldar
┌────────────────────┐ ┌────────────────────┐ ┌────────────────────┐
│ BASE DE DATOS │ │ ARCHIVOS SUBIDOS │ │ CÓDIGO │
│ │ │ │ │ │
│ 91 tablas │ │ uploads/terms/ │ │ repositorio git │
│ pacientes, turnos, │ │ uploads/turnero/ │ │ │
│ formularios, │ │ │ │ ya respaldado por │
│ firmas │ │ NO están en git │ │ estar en el remoto │
└────────────────────┘ └────────────────────┘ └────────────────────┘
crítico crítico cubierto
El código está a salvo por estar versionado. Los otros dos no tienen respaldo automático por el solo hecho de existir.
Base de datos
Es lo único irreemplazable. Contiene historia clínica, consentimientos firmados y facturación — información con valor legal y sin forma de reconstruirse.
mysqldump -h <host> -u <usuario> -p <base> \
--single-transaction --routines --triggers \
| gzip > respaldo_$(date +%F).sql.gz
--single-transaction evita bloquear las tablas mientras corre, así se puede hacer con el sistema en uso.
Qué contiene lo crítico
| Tabla | Por qué importa |
|---|---|
lab_pacientes |
Fichas clínicas |
turnero_consentimientos, lab_form_envios |
Formularios firmados — valor legal |
turnero_turnos, turnero_solicitudes |
Historial de atención y facturación |
terms_acceptance |
Aceptación de términos, ~5.000 registros |
admin_users, roles, role_modules |
Acceso al sistema |
Las firmas se guardan como imagen dentro de las tablas, no como archivos sueltos. Un respaldo de la base las incluye.
Archivos subidos
uploads/terms/ documentos de términos y condiciones
uploads/turnero/tv_media/ videos e imágenes de la pantalla de TV
No están en el repositorio. Al mover el sistema de servidor hay que copiarlos aparte, o los enlaces quedan apuntando a archivos que ya no existen.
Es exactamente lo que pasó con el documento de términos cuando cambió el dominio: la base seguía apuntando a una URL que ya no respondía.
Antes de un cambio riesgoso
Si va a tocar datos en producción, respalde solo lo que va a tocar:
mysqldump -h <host> -u <usuario> -p <base> role_modules admin_users \
> antes_del_cambio.sql
Es rápido y suele alcanzar. Un respaldo completo para cambiar una columna es desproporcionado; no tener ninguno es imprudente.
Verificar que el respaldo sirve
Un respaldo que nunca se restauró no es un respaldo, es un archivo:
gunzip -t respaldo_2026-08-03.sql.gz # ¿está íntegro?
zcat respaldo_2026-08-03.sql.gz | head -40 # ¿tiene lo que espera?
Lo ideal es restaurarlo de vez en cuando en una base de prueba y comprobar que el sistema arranca contra ella.
Qué NO es recuperable
Aunque tengas respaldos, hay datos que nunca se guardaron y no hay de dónde sacarlos:
| Dato | Desde cuándo existe |
|---|---|
| Quién creó cada consentimiento del turnero | 3 de agosto de 2026 |
| Quién firmó cada toma de F-LAB-28 | 3 de agosto de 2026 |
| Cédula del personal no enfermero | 3 de agosto de 2026 |
Los registros anteriores tienen esos campos vacíos, y no hay traza de auditoría que permita reconstruirlos. Vale como advertencia: cuando se agrega una columna para registrar quién hizo algo, lo anterior se pierde.