Backup y restauración

La base de datos guarda todo lo importante del negocio (usuarios, ventas, jornadas, premios). Es imprescindible mantener copias de seguridad.

1. Cuándo respaldar

• Automático diario (recomendado): una copia completa cada día.
• Tras cada jornada de sorteo: al cerrar la jornada y guardar el sorteo, hacer una copia del día.
• Antes de cualquier cambio estructural (migraciones o actualizaciones de versión).

2. Copia de seguridad (pg_dump)

En el servidor de producción (con permiso de la base de datos) ejecutar:

pg_dump "postgresql://loto_app:TU_CLAVE@localhost:5432/lotodb" \
  --file=backup-loto-$(date +%Y%m%d-%H%M).sql

O en formato comprimido (más ligera):

pg_dump "postgresql://loto_app:TU_CLAVE@localhost:5432/lotodb" \
  -Fc -f backup-loto-$(date +%Y%m%d-%H%M).dump

• Guardar el archivo fuera del servidor (otra máquina, disco offline o almacenamiento en la nube).
• Mantener al menos las últimas 30 copias (política definida por la operación).

3. Restauración

# 1) Crear (o vaciar) la base de datos de destino
createdb -h localhost -U loto_app lotodb

# 2) Restaurar desde el archivo
pg_restore -d "postgresql://loto_app:TU_CLAVE@localhost:5432/lotodb" backup-loto-20260101-0900.dump

En una restauración de emergencia la aplicación debe estar detenida durante el proceso para evitar escrituras concurrentes.

4. Verificación de la copia

• Toda copia debe probarse con una restauración en un entorno de prueba al menos una vez al mes.
• Verificar que el recuento de ventas y usuarios coincida con la operación real.

5. Script de sincronización de datos (desarrollo)

El repositorio incluye scripts/sync-from-prod.ts, que descarga la base de producción a una base local de desarrollo (solo lectura hacia producción; nunca escribe en el servidor). Se usa para:

• Probar errores reportados con datos reales.
• Validar cambios antes de publicarlos.

Uso:

npx tsx scripts/sync-from-prod.ts

Este es solo para desarrollo local, no constituye la copia de seguridad de producción (lea 06-doc adjunto: docs/sincronizacion-bd.md para una explicación completa del proceso).

6. Qué NO debe respaldarse

• node_modules, .next, archivos temporales.
• La base de datos de desarrollo (se recrea con pnpm prisma migrate dev y seed).
• Credenciales en texto plano: las contraseñas están cifradas con bcrypt en la BD (y la copia debe protegerse también).