# Procedimiento de copia de seguridad · Supabase Kynda

Cubre las tres exigencias del Anexo I, apartado 3.2, que la auditoría identificó
como incumplidas: copia de la base de datos, copia de los ficheros de Storage y
verificación comprobable de la restauración.

## 1. Preparar las credenciales (solo la primera vez)

Entra en el panel de Supabase con tu sesión y, **para cada uno de los dos proyectos**,
copia dos valores.

**Cadena de conexión** · `Settings` → `Database` → *Connection string* → pestaña **URI**.
Sustituye `[YOUR-PASSWORD]` por la contraseña real de la base de datos. Si no la
recuerdas, en esa misma pantalla puedes restablecerla con *Reset database password*;
ten en cuenta que después habrá que actualizarla en las variables de entorno de Vercel
y en los secretos de GitHub.

**Clave de servicio** · `Settings` → `API` → *Project API keys* → `service_role`.
Es la que permite descargar los ficheros de Storage.

Crea el fichero `~/Desktop/KYNDA/.backup-creds` con este contenido:

```
PROD_DB_URL=postgresql://postgres.lfgaaijrzkufkbxwhmjz:CONTRASEÑA@aws-0-REGION.pooler.supabase.com:5432/postgres
PROD_SERVICE_KEY=eyJ...
CERT_DB_URL=postgresql://postgres.lovcrkoofqffhdclxaxg:CONTRASEÑA@aws-0-REGION.pooler.supabase.com:5432/postgres
CERT_SERVICE_KEY=eyJ...
```

El script le aplica permisos `600` automáticamente. No lo subas a ningún repositorio.

## 2. Ejecutar

```bash
~/Desktop/KYNDA/scripts-backup/backup-supabase.sh
```

Genera una carpeta con fecha, `backup-supabase-AAAA-MM-DD_HHMM`, con esta estructura
por cada proyecto:

| Fichero | Contenido |
|---|---|
| `estructura.sql` | Tablas, funciones, triggers y políticas de seguridad |
| `datos.sql` | Todos los datos, en texto legible |
| `completo.dump` | Copia comprimida, la que se usa para restaurar |
| `storage/` | Fotografías de evidencia y portadas de campaña |
| `storage/INVENTARIO.tsv` | Listado de cada fichero con su tamaño |
| `MANIFIESTO.txt` | Huellas digitales, recuentos y recuento de filas en origen |

Se copian los esquemas `public`, `auth`, `storage` y `kynda`. Los gestionados por
Supabase quedan fuera a propósito: no son restaurables ni pertenecen al proyecto.

## 3. Verificar

El `MANIFIESTO.txt` incluye el recuento de filas por tabla **en origen**. Tras una
restauración, ese mismo recuento en destino debe coincidir. Ese contraste es el
ensayo de restauración que el contrato exige y que hasta ahora nunca se había hecho.

## 4. Restaurar

```bash
pg_restore --no-owner --no-privileges -d "postgresql://...DESTINO..." completo.dump
```

Los ficheros de Storage se vuelven a subir desde la carpeta `storage/`, respetando
la estructura de carpetas, que reproduce la de los buckets originales.

## 5. Periodicidad

El contrato exige retención mínima de treinta días. Para automatizarlo, añade a
`crontab -e` una línea como esta, que lo ejecuta cada día a las tres de la madrugada:

```
0 3 * * * /Users/danicosta/Desktop/KYNDA/scripts-backup/backup-supabase.sh >> ~/Desktop/KYNDA/backup.log 2>&1
```

Conviene además borrar las copias de más de treinta días y, sobre todo, **guardar
una copia fuera de este equipo**. Una copia en el mismo disco que el original no es
una copia de seguridad.

## Notas técnicas

Se usa `pg_dump` directamente y no la interfaz de línea de comandos de Supabase.
Esta última exige tener Docker en ejecución, y falla sin él. Comprobado durante la
preparación de este procedimiento.

## Requisitos

Ya instalados en este equipo: `pg_dump` y `psql` versión 18.6, mediante `brew install libpq`.