Sauvegarde et restauration

Skrum est le plan de contrôle de projet tout-en-un avec IA — chat d'équipe, tâches et sprints, réunions vidéo natives et activité de code entrante dans un seul espace de travail, où chaque action de l'IA attend un accord humain.

La sauvegarde relève de l'opérateur. Skrum fournit les scripts et le balayage de rétention ; vous fournissez le calendrier, une destination hors site, la supervision et les exercices de reprise.

Objectifs de reprise et calendrier

• Cadence recommandée : un jeu complet chaque nuit et un exercice trimestriel. Si une journée de pertes est inacceptable, sauvegardez toutes les six heures ou moins.
• RPO : au plus l'intervalle entre deux jeux réussis plus la durée d'une exécution interrompue. Une sauvegarde nocturne n'atteint 24 heures que si chaque exécution est surveillée et réussit.
• RTO : mesurez-le avec une restauration d'un volume proche de la production. Quatre heures constituent une cible initiale ; la mesure réelle fait foi.
• Rétention : comme point de départ, conservez 7 jeux quotidiens, 4 hebdomadaires et 12 mensuels, dont un hors de l'hôte applicatif et du stockage objet principal.

Alertez sur un lancement manqué, un code non nul ou l'absence de MANIFEST.txt. Ne supprimez pas le dernier jeu valide avant la présence complète du nouveau et de ses sommes de contrôle.

Créer une sauvegarde

./scripts/backup/backup-all.sh

Les scripts lisent uniquement les variables de sauvegarde depuis le .env à la racine lorsqu'elles sont absentes du processus. Les variables explicites, même vides, sont prioritaires ; le fichier n'est jamais exécuté par source ou eval et aucun secret n'est affiché.

MONGODB_URI, DATABASE_URL, S3_ENDPOINT, S3_ACCESS_KEY, S3_SECRET_KEY et S3_BUCKET sont requis. BACKUP_TARGET=local écrit sous BACKUP_DIR ; BACKUP_TARGET=s3 téléverse sous BACKUP_S3_PREFIX. Mongo, Postgres et les objets sont capturés séquentiellement ; suspendez les écritures et les workers pour un point de reprise calme et cohérent.

Balayage de rétention

Une tâche BullMQ quotidienne retention-sweep archive sans perte les messages, commentaires de tâches et événements du graphe de travail éligibles à la purge vers le stockage froid sous archive/{accountId}/{kind}/{sha256}.ndjson.gz avant suppression. Les jours de rétention par palier suivent historyDays (30 / 90 / 365 / illimité). Les paliers illimités ne font rien.

Attentes de restauration

La restauration est destructive : Mongo utilise --drop, Postgres --clean --if-exists et le miroir objet supprime les éléments excédentaires. Planifiez une maintenance, stoppez les écritures API/workers et confirmez les destinations.

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

La commande valide le manifeste et chaque hachage avant toute modification, puis restaure Mongo, Postgres et MinIO. Avant de rouvrir les écritures :

1. Démarrez l'API et les workers et attendez les contrôles de santé.
2. Testez la connexion, les lectures d'espace/projet/tâche/message et le téléchargement d'un fichier connu.
3. Vérifiez les files, les migrations et les événements d'audit récents.
4. Consignez les heures, le jeu restauré et le smoke test afin d'actualiser le RTO mesuré.

FAQ

• Hébergement géré ? Les sauvegardes sont notre responsabilité sur l'offre gérée.
• Puis-je remplacer la fenêtre de rétention ? Oui — les retention_policies par compte ne peuvent que la réduire.
• La rétention applicative remplace-t-elle les sauvegardes de reprise ? Non, le cycle de vie des jeux complets est une politique d'exploitation séparée.

Voir aussi: Documentation Skrum