Les processus de sauvegardes de la plateforme sont actuellement basés sur deux piliers principaux :
- une sauvegarde complète des machines ;
- une sauvegarde applicative via Longhorn.
¶ Machine
La sauvegarde machine est holistique : elle inclut l'ensemble de la VM/Machine complète contenant tout son état. Dans le cadre d'un déploiement sur site, elle est mise en place par le client avec comme impératifs :
- un emplacement de stockage distant des sauvegardes** **;
- un chiffrement au repos et en transit de la sauvegarde ;
- une fréquence journalière au minimum ;
- une durée de rétention de 14 jours minimum ;
- la nécessité pour Arkhn de planifier avec le client un test du processus de sauvegarde/restauration régulièrement (~24h ou au minimum hebdomadaire).
Dans un contexte cloud fourni par Arkhn, l'ensemble des systèmes mis à disposition possèdent : - un stockage distant des sauvegardes distant ;
- un site secondaire de remontée automatique en cas de perte du site principal ;
- un chiffrement de base des sauvegardes ;
- une sauvegarde 2 fois par jour ;
- une durée de rétention de 14 jours.
Nos hébergeurs étant certifiés HDS / ISO27001, l'ensemble de ces procédures est testée annuellement.
¶ Applicative
En complément de la sauvegarde précédente et en remplacement plus chirurgical à terme, une sauvegarde dite applicative est mise en place, qui se concentre dans son périmètre actuel sur :
- l'ensemble des Data Clean Rooms actives dans la plateforme ;
- l'ensemble des données non-structurées (MinIO) ;
- l'ensemble des données structurées de santé (ClickHouse) ;
- l'ensemble des traces du puit de log (ElasticSearch).
Pour le bon fonctionnement de cette sauvegarde, un emplacement réseau distant doit être mis à disposition, par ordre de préférence :
- un object storage type S3 ;
- un stockage selon le protocole NFS ;
- un stockage selon le protocole CIFS/Samba.
Ce stockage servant de sauvegarde doit être fiable. Il est généralement hébergé sur une architecture de stockage en réseau de type SAN ou NAS.
¶ Fonctionnement des sauvegardes incrémentales
Les sauvegardes Longhorn sont créées à partir d'un snapshot du volume et sont stockées dans un backupstore externe (NFS ou S3 compatible), indépendamment du cluster Kubernetes. Contrairement aux snapshots, qui sont locaux et conservent l'historique des modifications, une backup est une version "aplatie" de la chaîne de snapshots : elle reflète l'état du volume au moment du snapshot source, mais ne conserve pas l'historique des changements.
¶ Nature d'une backup : collection de blocs
- Une backup est constituée de blocs de 2 Mo, chacun compressé et stocké dans le backupstore.
- Seuls les blocs modifiés depuis la dernière backup sont transférés lors d'une nouvelle sauvegarde incrémentale, ce qui optimise l'espace et la bande passante.
- Si aucun bloc n'a changé, la nouvelle backup n'ajoute aucun bloc : elle pointe vers les blocs existants déjà présents dans le backupstore.
- Les blocs sont partagés entre les différentes backups du même volume, ce qui permet une certaine déduplication : un bloc inchangé est réutilisé par plusieurs backups.
- Les métadonnées de chaque backup (fichiers .cfg) sont très légères : elles contiennent uniquement les offsets et les checksums des blocs utilisés.
¶ Processus de sauvegarde et restauration
- La création d'une backup implique la copie des blocs modifiés via le réseau, ce qui prend du temps selon la quantité de données à transférer.
- Lors de la restauration, Longhorn récupère les blocs nécessaires à partir du backupstore pour reconstruire le volume : même si la backup est incrémentale, la restauration fournit l'intégralité du volume.
- La suppression d'une backup ne supprime pas immédiatement les blocs : un nettoyage périodique (garbage collection) retire les blocs non utilisés par d'autres backups
Cette approche sera progressivement généralisée dans le futur pour permettre des sauvegardes plus fines des différents composants de la plateforme.
¶ Abaque de dimensionnement SAN/NAS
Grâce aux optimisations mentionnées précédemment, nous pouvons tirer les abaques suivants de dimensionnement entre le stockage alloué aux données de la plateforme et le stockage nécessaire pour leur sauvegarde dans le cadre de données évoluant jour après jour :
| Taille du stockage (To) | Stockage nécessaire pour 14 jours de rétention (To) | Stockage nécessaire pour 30 jours de rétention (To) |
|---|---|---|
| 1 | 3,6 | 6,8 |
| 5 | 18 | 34 |
| 10 | 36 | 68 |
| 20 | 72 | 136 |
| 30 | 108 | 204 |
| 40 | 144 | 272 |
| 50 | 180 | 340 |
| 100 | 360 | 680 |
| 200 | 720 | 1360 |
| 500 | 1800 | 3400 |
Cet abaque est indicatif, et des déviations plus ou moins importantes peuvent être constatées selon l'utilisation plus ou moins intensive en réécriture des données.
Dans le cas de données n'évoluant plus, typiquement les archivages de Data Clean Room, le volume de données stockées devrait rester fixe.