# Persistencia de Redis (mínima, no es backup de negocio)

Redis guarda sesiones (`iam:session:*`) y cache (`core:cache:*`, ver
Fase 4e). Ninguno de los dos es fuente de verdad:

- Sesión perdida → el usuario hace login de nuevo. Molesto, no es pérdida
  de datos.
- Cache perdido → la siguiente lectura recalcula desde Postgres.

Por eso Redis **no** entra en la política de backup con retención/PITR de
las bases Postgres (Fase 6 del plan). Lo único que vale la pena es evitar
que un reinicio del contenedor Redis deslogueé a **todos** los tenants a
la vez -- eso se resuelve con RDB, no con un pipeline de backup.

## Configuración recomendada (solo producción)

```conf
# redis.conf del recurso de Coolify (o el equivalente que exponga)
save 900 1      # snapshot si hubo >=1 cambio en 15 min
save 300 10     # snapshot si hubo >=10 cambios en 5 min
save 60 10000   # snapshot si hubo >=10000 cambios en 1 min
appendonly no   # AOF no hace falta -- RDB alcanza para el objetivo (evitar
                # deslogueo masivo), y agrega complejidad/IO sin beneficio
                # dado que nada aquí es irremplazable.
```

En dev/staging, ni siquiera hace falta esto -- perder las sesiones de
desarrollo no tiene costo real.

## Qué NO hacer

- No configurar `pgbackrest`/backups con retención larga para Redis --
  sería tratar como "fuente de verdad" algo que por diseño no lo es.
- No mezclar la política de respaldo de Redis con la de Postgres en la
  misma automatización -- son necesidades distintas (ver Fase 6 del plan).