# 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.

```bash
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**:

```bash
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:

```bash
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.