Fiabilité et reprise après sinistre
La plateforme stocke certaines données qui doivent être sauvegardés et restaurés en cas de sinistre.
Sauvegarde
La sauvegarde de la plateforme est effectuée par l'administrateur système en assurant la sauvegarde des éléments suivants :
| Élément | Niveau de criticité | Fréquence recommandé de sauvegarde |
|---|---|---|
| Postgresql | ➕➕➕ ⚠️ Critique ⚠️ | Quotidienne |
| S3 | ➕➕ Modérée | Hebdomadaire |
| Agents | ➕➕ Modérée | (peut être sauvegardé par PVC pour garantir une continuité de service optimale) |
| Redis | ➕ Faible (stateless) | (peut être sauvegardé par PVC pour garantir une continuité de service optimale) |
| Frontend | Nulle (stateless) | Aucune |
| Backend | Nulle (stateless) | Aucune |
Postgresql
Dans le déploiement par kubernetes, la sauvegarde peut être configuré en utilisant la fonctionnalité de backup du helm bitnami
Par défaut avec le helm QALITA, cette sauvegarde n'est pas activité, une fois activé, la sauvegarde est effectuée dans un PVC qui doit lui-même faire l'object d'une sauvegarde dans un stockage à froid ou semi-froid.
S3
Le stockage S3 est moins critique que la base de données car il ne contient que des logs ou les archives des packs dont le code est déjà versionné dans un système comme gitlab. Dans le cas d'une défaillance, la restauration du stockage S3 et la perte de donnée est donc moins critique.
Dans le déploiement par kubernetes, la sauvegarde du stockage S3 s'effectue en sauvegardant le PVC qui contient les données.
PVC et sauvegarde : La sauvegarde des PVC est généralement de la charge de l'administrateur du cluster Kubernetes. Si vous n’avez pas la charge de la gestion de votre cluster Kubernetes, veillez à bien vérifier que les PVC sont sauvegardés en contactant l'administrateur du cluster.
Agent
Pour leur fonctionnement, les agents doivent stocker des informations relatives :
- Aux sources (fichier
qalita-conf.yaml) : pour atteindre les chemins de fichiers ou requêter les bases de données, ces informations ne sont pas stockés dans la plateforme, il est donc important de sauvegarder ce fichier ou garantir sa persistance. Dans le déploiement qalita il est possible d'activer le déploiement d'un agent local, et d'activer la persistance du dossier~/.qalita/pour garantir la persistance de ces informations. - A la connexion à la plateforme (fichier
.agent) contient les informations de la dernière connexion à la plateforme. Voir la documentation sur la configuration de l'agent,
Il est fortement recommandé d'utiliser les variables d'environnement pour l'authentification. Cependant dans le mode d'authentification par fichier, un fichier .env-<login> contenant les informations de connexion à la plateforme pour un certains utilisateur <login>, ces fichiers sont temporaires, contiennent des informations sensibles et ⚠️ ne doivent pas être sauvegardés ⚠️.
- Aux résultats d'exécutions des packs (dossier
~/.qalita/agent_temp_run/) contient les résultats d'exécutions des packs, il est possible de configurer le dossier~/.qalita/agent_temp_run/pour qu'il soit persistant et sauvegardé.
Restauration
Postgresql
Pour restaurer une sauvegarde Postgresql référez-vous à la documentation Bitnami
S3
Pour restaurer une sauvegarde S3, référez-vous à la documentation SeaweedFS
Agents
- Réenregistrement de l'agent dans la plateforme :
Pour restaurer les informations d'un agent, il suffit de relancer un agent,
qalita agent loginet de copier le dossier~/.qalita/de l'agent. - Restauration des sources :
Il faut ensuite restaurer le fichier de configuration des sources
qalita-conf.yaml. - Synchronisation des id de sources avec la plateforme :
Il faut ensuite synchroniser les id de sources avec la plateforme, pour cela il faut utiliser la commande
qalita source push. Cela réattribuera les id de sources aux sources locales, permettant de bien associé les tâches à effectuer sur les sources, ainsi que leurs résultats.