Sauvegarde de la base de données — vue métier
À quoi ça sert ?
Section intitulée « À quoi ça sert ? »Toutes les 4 heures, on fait une copie complète de la base de données principale d’erevo (apprenants, sessions, produits, classes virtuelles, données DPC, etc.) et on l’envoie sur un serveur dédié aux sauvegardes. C’est le filet de sécurité : si un incident arrive sur la base (crash matériel, corruption, mauvaise manipulation), on peut remonter à la dernière copie datant de moins de 4 heures.
Chaque sauvegarde est conservée avec sa date et son heure, et on garde aussi en permanence une copie nommée « latest » prête pour une restauration rapide.
Quand ça tourne ?
Section intitulée « Quand ça tourne ? »Toutes les 4 heures, en continu, toute la journée (heure de Paris : minuit, 4h, 8h, midi, 16h, 20h).
Ce que ça change concrètement
Section intitulée « Ce que ça change concrètement »- Aucune différence visible côté utilisateurs (apprenants, formateurs, CSM) : la tâche n’écrit rien dans la plateforme, elle ne fait que lire et copier.
- Sur le serveur de backup, un nouveau fichier de sauvegarde apparaît toutes les 4 heures, horodaté. Le fichier « latest » est toujours mis à jour à la dernière copie.
Qui est concerné ?
Section intitulée « Qui est concerné ? »- Équipe IT : seule à consommer ces sauvegardes, en cas d’incident ou pour restaurer un environnement de test.
- Tout le reste de l’entreprise indirectement : si la base principale se perd, c’est grâce à ces sauvegardes qu’on remet la plateforme en état.
Cas connus / points d’attention
Section intitulée « Cas connus / points d’attention »- Pas de remontée automatique en cas d’échec : la tâche est 100 % shell (pas de code applicatif) et n’est donc pas couverte par Sentry. Un échec ne se voit qu’en allant regarder manuellement la page des tâches planifiées côté GitLab. À garder en tête.
- La copie se fait pendant que la plateforme continue de tourner ; il est donc théoriquement possible qu’une sauvegarde attrape une donnée en cours d’écriture (incohérence transactionnelle très rare en pratique sur notre usage, mais à garder en tête).
Qui est alerté si ça plante ?
Section intitulée « Qui est alerté si ça plante ? »Personne automatiquement. C’est l’équipe IT qui doit aller vérifier manuellement côté GitLab que chaque passage s’est bien terminé. À traiter en priorité (un canal d’alerting dédié reste à mettre en place).
Détails techniques (équipe IT) : voir Backup base de données.