Je me suis aperçu, avec surprise, que les décideurs et même parfois les personnes issues du sérail technique, n’avaient pas les idées claires sur ce qu’est réellement l’archivage de données. Et, surtout, confondent allègrement archivage et sauvegarde. Il peut être utile de clarifier ces notions.

L’angle d’attaque le plus efficace est celle de la réponse à un risque : archivage, sauvegarde, PCA-PRA sont des réponses techniques à un (ou plusieurs) risques techniques, le voir comme tel rend les concepts beaucoup plus clairs.

Quand vous stockez des données informatiques sur un support (clé USB, disque dur interne ou externe, etc.), le premier risque auquel vous faites relève tout simplement d’une défaillance physique du support : panne mécanique, corruption d’un composant, etc. À une défaillance physique, la meilleure réponse est le dédoublement du composant, avec des systèmes d’écriture en temps réel type « écriture en Y » ou le bon vieux RAID : Redundant Array of Independent Disks, ce qui signifie « regroupement redondant de disques indépendants ». C’est la même stratégie de dédoublement qui conduit à mettre deux réacteurs dans des avions de ligne, et aussi deux pilotes.

Mais si le local dans lequel sont situés ces deux supports dédoublés (on pense à un datacenter qui héberge le serveur avec ses disques en RAID 5) part en fumée ou est inondé, le dédoublement ci-dessus ne sert à rien. C’est là qu’intervient le concept de PCA-PRA (ou plutôt de PSI pour être exact), avec dédoublement de salles, de sites, d’adduction réseau, d’arrivées électriques, de climatisation, etc.

Là encore, la réponse à un risque physique (perte d’une salle) est le dédoublement du « composant » (la salle). On suppose, pour le besoin de la démonstration, que les deux serveurs dans les deux salles sont en miroir (c’est-à-dire à chaque instant la copie physique exacte et en temps réel l’un de l’autre). A ce stade, chaque serveur est en RAID5, et a un frère jumeau à quelques kilomètres, lui aussi en RAID5. À tout moment, une donnée écrite sur l’un est aussi écrite sur l’autre. Idem pour les modifications et les suppressions.

Mais si d’aventure une donnée était effacée par mégarde (mauvaise manipulation humaine, malveillance, bug logiciel, etc.) de l’un des serveurs, elle le serait aussi de l’autre. Le dédoublement physique n’est donc pas une réponse à un effacement logique (ou à une corruption de type ransomware). La réponse à une défaillance logique est la sauvegarde : on restaurera les données de la veille, de l’avant-veille, du mois dernier, etc. Nous ne rentrons pas, à ce stade, dans des considérations de temps de sauvegarde, de fenêtre temporelle, de RTO (Return Time Objective), de RPO (Return Point Objective), de temps de restauration, etc. qui nécessitent à eux seuls un chapitre entier, voire plusieurs. Et tant que l’on y est, il faut aussi dédoubler la sauvegarde.

À ce sujet tout de même, si la réponse « classique » à un ransomware est la sauvegarde, dans les faits c’est plus compliqué car mettre en offline des sauvegardes de milliers de serveurs chaque nuit est un vrai défi, sans parler du temps de restauration de toute une infrastructure complexe (à ma connaissance aucun CHU ne l’a jamais testé).

À ce stade le lecteur pense que la boucle est bouclée, mais en fait non. Je garde toujours sur moi une vieille disquette 5 pouces 1/4 pendant les conférences, que je tends à un auditeur en lui demandant d’imprimer un fichier Lotus 1-2-3 qui se trouve dessus. En faisant cela, je confronte l’assistance à deux problèmes simultanés : l’obsolescence physique du support (bon courage pour retrouver le lecteur de disquette, le PC avec les bons connecteurs, l’OS antédiluvien et j’en passe) et l’obsolescence logique du format (même si des filtres existent, je vous mets au défi de relire une base de données ORACLE 1.0, en tout cas en un temps raisonnable).

Bref, la réponse à l’obsolescence physique ou logique n’est ni le dédoublement du support ni la sauvegarde : c’est l’archivage. Cela consiste à exporter, à intervalles réguliers des données inactives vers un support physique qui devra régulièrement migrer (des baies de disques) et dans un format logique dont on est à peu près certain qu’il sera toujours lisible dans 50 ans (le PDF/A est un bon candidat), le tout accompagné de métadonnées de type XML car on ne peut pas facilement requêter sur des collections de fichiers PDF.

Si vous ne voyez pas quel type de données nécessiterait d’être conservées sur des décennies, il n’y a quel l’embarras du choix : les données médicales évidemment (entre 20 ans et 100 ans selon les cas), mais aussi les données RH (45 ans, soit toute la carrière de l’agent) sans compter les fichiers de l’état civil, les archives notariales, etc.

Ah, j’allais oublier : votre support d’archives numériques peut aussi devenir « à valeur probante ou probatoire ». Cela nécessite de mettre en place un système de signatures avec certificats, renouvelés régulièrement (les capacités de cassage de chiffrement ne seront pas les mêmes dans 20 ans).

Ah et j’allais aussi oublier : le support retenu pour l’archivage (une baie de disques dans la plupart des cas) devra aussi migrer à intervalles réguliers (au moins tous les 10 ans). Ah oui, et j’allais encore oublier : votre support d’archives, il faut le dédoubler ! Et le sauvegarder ! Et dédoubler la sauvegarde.

Restez informés en temps réel
S'inscrire à
la newsletter
En fournissant votre email vous acceptez de recevoir la newsletter de Incyber et vous avez pris connaissance de notre politique de confidentialité. Vous pourrez vous désinscrire à tout moment en cliquant sur le lien de désabonnement présent dans tous nos emails.
Restez informés en temps réel
S'inscrire à
la newsletter
En fournissant votre email vous acceptez de recevoir la newsletter de Incyber et vous avez pris connaissance de notre politique de confidentialité. Vous pourrez vous désinscrire à tout moment en cliquant sur le lien de désabonnement présent dans tous nos emails.