Copia de seguridad y restauración

Skrum es el plano de control de proyectos con IA todo en uno — chat de equipo, tareas y sprints, reuniones de vídeo nativas y actividad de código entrante en un solo espacio de trabajo, con cada acción de la IA a la espera de un sí humano.

La copia de seguridad es responsabilidad del operador. Skrum incluye scripts y el barrido de retención; tú aportas la programación, un destino externo, la monitorización y los simulacros de recuperación.

Objetivos de recuperación y programación

• Frecuencia recomendada: un conjunto completo cada noche y un simulacro trimestral. Si no se puede tolerar la pérdida de un día, ejecuta copias cada seis horas o menos.
• RPO: como máximo el intervalo entre conjuntos correctos más la duración de una ejecución interrumpida. La copia nocturna solo logra 24 horas si cada ejecución se supervisa y termina correctamente.
• RTO: debe medirse restaurando un volumen similar al de producción. Cuatro horas es un objetivo operativo inicial; manda el resultado medido.
• Retención: como punto de partida, conserva 7 conjuntos diarios, 4 semanales y 12 mensuales, con al menos una copia fuera del host y del almacén de objetos principal.

Genera alertas por ejecuciones omitidas, códigos distintos de cero o ausencia de MANIFEST.txt. No borres el último conjunto válido hasta completar el nuevo y sus sumas de comprobación.

Crear una copia

./scripts/backup/backup-all.sh

Los scripts leen únicamente las variables de copia desde el .env de la raíz cuando faltan en el proceso. Las variables explícitas, incluso vacías, tienen prioridad; el archivo no se ejecuta con source ni eval y ningún secreto se imprime.

Se requieren MONGODB_URI, DATABASE_URL, S3_ENDPOINT, S3_ACCESS_KEY, S3_SECRET_KEY y S3_BUCKET. BACKUP_TARGET=local escribe en BACKUP_DIR; BACKUP_TARGET=s3 sube bajo BACKUP_S3_PREFIX. Mongo, Postgres y los objetos se capturan de forma secuencial; pausa las escrituras y los workers para obtener un punto de recuperación tranquilo y coherente.

Barrido de retención

Un trabajo diario de BullMQ llamado retention-sweep archiva sin pérdida de datos los mensajes, comentarios de tareas y eventos del grafo de trabajo que cumplen los criterios de poda en almacenamiento en frío bajo archive/{accountId}/{kind}/{sha256}.ndjson.gz antes de eliminarlos. Los días de retención por nivel siguen historyDays (30 / 90 / 365 / ilimitado). Los niveles ilimitados no hacen nada.

Expectativas de restauración

La restauración es destructiva: Mongo usa --drop, Postgres --clean --if-exists y el espejo de objetos elimina contenido sobrante. Programa mantenimiento, detén las escrituras de API/workers y confirma los destinos.

./scripts/backup/restore-all.sh <BACKUP_SET_DIR_OR_S3_URI>

El comando valida el manifiesto completo y todos los hashes antes de modificar datos y después restaura Mongo, Postgres y MinIO. Antes de reabrir las escrituras:

1. Inicia API y workers y espera a que los healthchecks sean correctos.
2. Comprueba inicio de sesión, lecturas de espacio/proyecto/tarea/mensaje y la descarga de un archivo conocido.
3. Revisa colas, migraciones y eventos de auditoría recientes.
4. Registra inicio, fin, conjunto restaurado y resultado del smoke test para actualizar el RTO medido.

Preguntas frecuentes

• ¿Alojamiento gestionado? Las copias de seguridad son responsabilidad nuestra en el nivel gestionado.
• ¿Puedo anular la ventana de retención? Sí — retention_policies por cuenta la reduce, nunca la amplía.
• ¿La retención de la aplicación sustituye las copias de recuperación? No; el ciclo de vida de los conjuntos completos es una política operativa independiente.

Ver también: Documentación de Skrum