Sauvegarde et restauration du système

Le service de sauvegarde intégré protège la configuration du système Private Cloud Appliance contre la perte et la corruption de données. Il stocke les données requises pour le fonctionnement du système et du service afin que tout service ou composant crucial puisse être restauré à son dernier état de santé connu. Les sauvegardes des environnements d'utilisateur dans Compute Enclave ne sont pas incluses.

Les systèmes de fichiers suivants sont sauvegardés :

• Projet PCA : obj_share et MGMT_ROOT

• public_ostore_project : Systèmes de fichiers liés à chaque location créée sur le bâti (pour les opérations COS)

• Projet private_ostore : Système de fichiers dans private_ostore_project

Conformément au modèle de déploiement basé sur les microservices, le service de sauvegarde orchestre les différentes opérations de sauvegarde sur l'ensemble du système et assure la cohérence et l'intégrité des données, mais il ne définit pas les exigences de sauvegarde de composant individuel. Cette logique fait partie des plugins de sauvegarde des composants.

Le plugin de sauvegarde est l'élément clé qui détermine quels fichiers sont sauvegardés pour un composant système ou un service donné, et comment les données sont collectées. Par exemple, une simple copie de fichier peut fonctionner pour certains fichiers alors qu'un instantané est requis pour d'autres données, ou dans certains cas, un service peut devoir être arrêté pour permettre la création de la sauvegarde. Le plugin détermine également la fréquence de sauvegarde et le temps de conservation. Chaque plugiciel s'inscrit au service de sauvegarde afin que le service de sauvegarde soit au courant des plugiciels actifs et puisse programmer les opérations de sauvegarde requises de manière cohérente en tant que Kubernetes CronJobs. Les plugiciels sont agrégés dans un profil de sauvegarde. Ce profil correspond à la liste des tâches exécutées par le service de sauvegarde lors de l'exécution d'une tâche de sauvegarde.

Les données de sauvegarde collectées via les plugins sont ensuite stockées par le service de sauvegarde dans un partage NFS dédié sur le ZFS Storage Appliance interne, à l'aide du chiffrement ZFS pour garantir la sécurité des données au repos. Si nécessaire, les fichiers de sauvegarde peuvent éventuellement être répliqués vers un emplacement de stockage externe.

Lors de la restauration d'un service ou d'un composant à partir d'une sauvegarde, le service repose à nouveau sur la logique fournie par le plugiciel. Un processus de restauration des composants comporte deux phases principales : la vérification et la gestion des données. Dans la phase de vérification, la sauvegarde est évaluée pour l'exhaustivité et la pertinence par rapport à l'état actuel du composant. Dans la phase de gestion des données, les actions requises sont effectuées pour arrêter ou suspendre un composant, remplacer les données et redémarrer ou reprendre le fonctionnement normal. Comme pour la sauvegarde, les opérations de restauration des données sont spécifiques au composant en question.

La mise en oeuvre de sauvegarde et de restauration par défaut consiste à effectuer toutes les tâches dans un profil de sauvegarde global qui couvre la base de données de la grappe MySQL, un instantané des projets ZFS sur le boîtier de stockage et tous les plugiciels de sauvegarde de composant enregistrés. Le profil par défaut est traité quotidiennement à minuit UTC et dispose d'une politique de conservation de 14 jours; les anciennes sauvegardes sont supprimées. Les sauvegardes sont stockées dans /nfs/shared_storage/backups/backup_*. Toutes les opérations de restauration doivent être effectuées manuellement, par composant.