Chaque ingénieur·e système, ou presque, pourvu qu'il ou elle ait quelques années d'expérience, a un jour ou l'autre entendu un·e stagiaire ou une personne récemment arrivée dans l'équipe s'étonner qu'on fasse encore des sauvegardes ou qu'on pose la question de la politique de sauvegarde d'une application métier.
Faire des sauvegardes ? C'est un truc de paléo-informatique, de boomer, ça ! Sur des bandes magnétiques, en plus ? De toute façon, les données sont stockées dans le Cloud ou sur un disque RAID !
Erreur, jeune padawan... erreur !
Les données d'une entreprise constituent son bien le plus précieux
... après ses ressources humaines (mais peut-on décemment qualifier les ressources humaines de "bien" ?)
Une entreprise, ou une organisation, ne se remet que très rarement et très difficilement de la perte totale et définitive de ses données.
Essayez d'imaginer l'état dans lequel se retrouverait une entreprise qui d'un coup d'un seul ne saurait plus quel est l'état de ses stocks, ni quel est l'avancement de ses différents projets, ni même qui sont ses employés, ni quels fournisseurs ont déjà été payés et quand, ni lesquelles des factures qu'elle a émises ont déjà été réglées par les clients ou celles qui restent dues, etc. etc. Il faudrait une énergie colossale et un nombre impressionnant de semaines, et même plutôt de mois, pour que cette entreprise arrive à se remettre d'un tel choc, pour qu'elle puisse reprendre une activité normale, ou ne serait-ce que quasi normale.
Imaginez la perte financière que représenterait la disparition du jour au lendemain de centaines, voire de milliers, d'heures de travail de plusieurs dizaines d'employé·e·s qui avaient produit et traité les données disparues ou corrompues lors d'un incident.
Une entreprise qui ne prend pas suffisamment soin de ses données ne peut pas être véritablement résiliente.
Elle met son business en danger, en grave danger.
Les risques qui pèsent sur les données sont nombreux
Où que se trouvent les données d'une entreprise ou d'une organisation, de nombreux risques pèsent sur celles-ci.
Qu'il s'agisse de la comptabilité d'une association, enregistrée dans un fichier Excel® stocké sur le disque dur du seul ordinateur de l'association ; qu'il s'agisse du code Java ou Python du dernier logiciel en cours de développement dans une entreprise de 200 salariés ; qu'il s'agisse de la base de données RH/paye d'une entreprise de 2000 personnes... toutes ces données sont menacées en permanence quant à leur disponibilité, leur confidentialité et leur intégrité.
Et il n'y pas que les pirates activistes à la solde de régimes dictatoriaux ou les mercenaires au service de mafias discrètes qui menacent ces données. Une inondation ou un incendie dans les locaux de l'entreprise, une erreur de manipulation de la part d'une personne de bonne foi, un café renversé par maladresse sur le portable de l'association, un coup d'aspirateur un peu violent dans le disque dur partagé du studio d'architecte, ...
Chaque risque doit trouver sa parade, en fonction des enjeux et du budget.
Le stockage redondant protège, mais de quoi ?
Redondance locale - RAID
Ce qu'on appelle stockage redondant, c'est en général l'ensemble des technologies RAID qui consiste à regrouper et assembler plusieurs disque durs, physiques, et à les combiner en un seul disque dur, logique. Le disque logique, ou "volume RAID", est celui que le système utilise et sur lequel sont stockées et traitées les données.
Chaque écriture sur le volume RAID sera répercutée sur tous les disques physiques qui composent le volume. Cette répartition redondante des données est réalisée selon un algorithme caractéristique du niveau de RAID choisi. Ainsi, si jamais un des disques physiques tombe en panne, les données présentent sur les autres disques physiques permettent d'une part de servir à la volée l'intégralité des données du volume et d'autre part de reconstituer le contenu du disque perdu.
Le remplacement du disque physique défectueux, et la reconstitution de son contenu à partir des disques physiques sains au sein du volume RAID, permettront de retrouver le niveau de fiabilité du volume. Selon la technologie RAID mise en œuvre, les performances du volume RAID restent en général dégradées tant que la reconstruction du contenu disque physique défectueux n'est pas achevée sur le disque de remplacement.
Puisqu'il existe plusieurs algorithmes RAID pour combiner des disques durs, chacun a ses caractéristiques propres, ses avantages, ses inconvénients, ses coûts... et donc ses usages typiques.
Le stockage redondant est tolérant aux pannes (des disques durs). La mise en œuvre pratique du RAID peut-être réalisée de manière logicielle ou matérielle :
- Dans le premier cas, c'est le système d'exploitation qui dépense un peu de puissance de calcul pour appliquer l'algorithme RAID aux disques physiques qui sont connectés à la machine,
- Dans le second cas, une carte RAID physique est installées dans la machine et c'est l'électronique embarquée sur cette carte qui fait tout le travail d'assemblage et de gestion des disques physiques qui sont connectés à la carte. Le système d'exploitation ne voit lui que le ou les volume(s) RAID résultant(s).
Donc oui, le stockage redondant protège effectivement les données stockées, mais uniquement contre un crash de disque dur.
Redondance géographique - Réplication
Les entreprises d'une certaine taille, ou répondant à certains enjeux importants, peuvent être amenées à considérer l'utilisation de plusieurs site géographiques, plus ou moins éloignés les uns des autres, pour héberger leurs données et leur production informatique.
Les fabricants de systèmes de stockage centralisé/mutualisé, tels que les baies SAN ou les NAS, proposent presque tous des fonctions de réplication du stockage d'un système à un autre. Cela apporte ainsi une redondance supplémentaire, au niveau géographique cette fois-ci.
Non seulement les données sur un site sont protégées contre une défaillance matérielle d'un disque physique mais elles sont aussi protégées conne une défaillance qui toucherait le système de stockage centralisé/mutualisé d'un site.
Limites
Quand un fichier stocké sur un volume RAID est supprimé ou réécrit, le fichier est supprimé/réécrit sur tous les disques physiques qui composent le RAID.
De même, la suppression ou la réécriture du contenu d'un fichier sur un site sera propagée sur les autres sites.
La réplication des données entre deux systèmes de stockage centralisé/mutualisé connait ses limites propres, et notamment celles qui découlent de la finitude des vitesses de propagation de l'électricité et de la lumière et impacte donc le temps nécessaire à la réplication des données d'un site à l'autre.
Les sauvegardes protègent, différemment
Sauvegarder les données, c'est faire une copie à un instant T de ces données depuis leur support "habituel" vers un support dédié à la sauvegarde. Cette copie de sauvegarde est aussi appelée backup.
L'objectif de la sauvegarde c'est de pouvoir revenir à cet instant T :
- Si jamais la donnée a été supprimée à T + 2 heures, ou à T + 2 jours, on restaure la sauvegarde et on revient à l'instant T,
- Si jamais la donnée a été modifiée (ou corrompue) à T + 3 heures ou à T + 3 mois et qu'on a besoin de retrouver l'état de la donnée à l'instant T, on restaure la sauvegarde,
- Si jamais la donnée a été perdue à T + 1 heure ou à T + 1 semaine à la suite d'un sinistre à l'endroit où elle se trouvait, on restaure la sauvegarde de l'instant T.
Évidement, dès qu'on a quelques gigaoctets de données à protéger il va falloir tenir un journal des sauvegardes qui sont réalisées. Il est en effet capital de savoir précisément d'où viennent les données sauvegardées et quand elles ont été sauvegardées. C'est le rôle de l'outil de sauvegarde. Il en existe plusieurs, certains Open Source, chacun ayant sa propre philosophie, ses avantages, ses inconvénients, ses coûts.
Politique de sauvegarde
La politique de sauvegarde consiste notamment à déterminer pour chaque ensemble de données les réponses à quelques questions de base :
- Dans tout l'ensemble qui constitue la donnée, il faut déterminer explicitement ce qui a vraiment de la valeur,
- La donnée que l'on s'apprête à sauvegarder est-elle une donnée de première main (golden source) ou bien n'est-elle que la duplication d'une donnée déjà sauvegardée à la source ?
- Existe-t-il des contraintes légales ou règlementaires qui imposent de sauvegarder certaines informations ?
- Avec la donnée elle-même faut-il également sauvegarder les informations relatives aux traitements ? Faut-il aussi sauvegarder les logiciels qui permettent ces traitements ?
À quel moment de la journée, de la semaine, du cycle de traitement(s) de la donnée...
- Faut-il s'assurer que la donnée soit logiquement/fonctionnellement cohérente avant de la sauvegarder ?
- Peut-on copier directement des fichiers du disques durs vers le support de sauvegarde, ou bien faut-il d'abord exporter les données puis copier ces exports ?
- Si l'opération de sauvegarde limite/impacte les traitements sur les données, de combien de temps dispose-t-on pour sauvegarder la données ?
- Existe-t-il des contraintes légales ou règlementaires qui imposent de chiffrer, ou d'anonymiser, une partie des données ?
- Sauvegarder la donnée va créer une nouvelle copie (au moins une), en termes de confidentialité ce n'est pas anodin.
- Les opérations de sauvegardes peuvent avoir un impact sur la performance d'accès ou de traitement des données.
- Existe-t-il des contraintes légales ou règlementaires qui imposent (ou interdisent) de copier les données sur un type de supports en particulier ?
- Quel support est le plus adapté aux caractéristiques de la données et à ses contraintes ?
- Quel support permettra le plus facilement de purger les sauvegardes en cas d'obligation ?
- Existe-t-il des contraintes légales ou règlementaires qui imposent d'éloigner géographiquement les copies de sauvegarde par rapport à la donnée initiale ?
- Existe-t-il des contraintes légales ou règlementaires qui imposent de conserver les données pendant une durée minimale (obligation de rétention) ?
- Existe-t-il des contraintes légales ou règlementaires qui interdisent de conserver les données au-delà d'une durée maximale (obligation de purge/suppression, droit à l'oubli) ?
- Que faut-il faire des sauvegardes précédentes quand la donnée est de nouveau sauvegardée après une modification ?
- Que faut-il faire des sauvegardes précédentes quand la donnée a été supprimée à son emplacement d'origine ?
- Existe-t-il des obligations légales ou règlementaires qui imposent de signer numériquement les sauvegardes pour garantir leur immutabilité ou leur inaltérabilité ?
- Combien de copies de sauvegarde faut-il générer ?
- Quand la donnée évolue rapidement, quelle "fraîcheur" de la donnée est-on autorisé à sacrifier ?
- De quels événements veut-on protéger la donnée ?
- Faut-il envisager la destruction totale du site où se trouve initialement la donnée ?
- En combien de temps faudra-t-il recouvrer l'accès à la donnée perdue/détruite ?
Il faut se poser ces questions pour chaque ensemble de données, pour chaque application métier.
On notera que la loi française dites "Informatique et Libertés" et le règlement européen dit RGPD vont notamment compter dans les réponses à la question "COMBIEN de TEMPS".
Une très grande partie des réponses ne peut être fournie que par le propriétaire des données.
En effet, par exemple, pour des données comptables, seule l'équipe comptabilité pourra répondre aux questions "QUAND" et "COMBIEN DE TEMPS".
En marge de la politique de sauvegarde à proprement parler, il faut aussi traiter avec soin le cycle de vie des copies de sauvegarde :
- D'une part, il faut anticiper l'obsolescence du matériel et du logiciel qui servent à réaliser les sauvegardes, à en garder la trace et à procéder aux restaurations,
- D'autre part, il faut impérativement vérifier régulièrement l'état des copies de sauvegarde et de leurs supports. En effet, certains supports sont sujets à dégradation au cours du temps ; lorsque les supports sont amovibles, l'inventaire et la localisation doivent être précis ; les supports peuvent eux-mêmes être sujets à obsolescence,
- Enfin, quand une copie de sauvegarde expire à la fin de la durée de rétention des données, il faut procéder à sa destruction de manière contrôlée : vérifier que l'obligation de purge est bien respectée et que le support de sauvegarde ne garde pas de traces des données qui pourraient être exploitées (par une personne malveillante notamment)
Certains logiciels de sauvegarde procèdent d'eux-mêmes à la relecture des copies de sauvegarde pour "compacter" les données sur les supports. En effet, les données sur un même support n'ont pas forcément la même durée de rétention. Et ces logiciels peuvent utiliser les copies multiples des sauvegardes pour régénérer les supports qui auraient été altérés ou perdus.
La question du budget dont on dispose est évidemment cruciale, elle conditionne ce qui est réellement faisable et donc le niveau de qualité des pratiques de sauvegarde par rapport aux ambitions posées par la politique de sauvegarde.
Les limitations ou restrictions de budget ne sont en aucun cas une justification acceptable pour une absence de politique de sauvegarde. Il n'y a aucune justification possible à l'absence de politique de sauvegarde. Même minimaliste, la politique de sauvegarde doit exister !
La règle "3 - 2 - 1" des sauvegardes
Cette règle synthétique est une bonne pratique que les ingénieur·e·s spécialistes des sauvegardes utilisent pour vérifier que la politique et les pratiques de sauvegarde permettront de restaurer les données le moment venu.
En plus de la donnée initiale, celle qui sert "vraiment" (la production), il faut (au moins) deux copies de sauvegarde, donc un total de trois copies.
La donnée initiale est en général sur un disque dur, il faut que les copies de sauvegardes se trouvent chacune sur un support physiquement différent, et même mieux : technologiquement différents et géographiquement distinct. Donc deux supports différents.
Au moins une des copies de sauvegarde doit se trouver dans un site géographique distinct et distant de la donnée initiale, idéalement cette copie est également "hors ligne".
Avoir une des copies de sauvegarde "hors ligne" consiste à faire en sorte que cette copie ne puisse pas être manipulée sans une intervention physique humaine. Par exemple, pour sortir une bande/cassette du coffre-fort et la remettre dans une bibliothèque automatisée. Ainsi, il n'est pas possible à une personne malintentionnée, ou a une défaillance du logiciel de sauvegarde, d'effacer cette copie de sauvegarde par des moyens électroniques/informatiques.
Restauration
Une politique de sauvegarde doit être accompagnée de ce qu'on pourrait appeler une "politique de restauration".
Tout d'abord, cette politique de restauration doit définir le cadre dans lequel les restaurations sont réalisées. C'est-à-dire par quel processus le besoin de restauration est exprimé, sa légitimité est vérifiée, qui prend en charge les opérations de restauration, comment sont-elles conduites et dans quelles conditions leur résultat est mis à disposition du demandeur.
Toutes sortes de problèmes peuvent empêcher d'utiliser les données sauvegardées pour les restaurer ou tout simplement pour les utiliser correctement une fois restaurées : politique de sauvegarde inadaptée (mauvaises réponses aux QUOI, QUAND, COMMENT notamment), copies de sauvegarde manquantes ou corrompues, ...
Il est donc crucial de tester régulièrement et fréquemment la restauration des sauvegardes en procédant à des tests de restauration. Évidemment, il s'agit ici de restaurer les copies de sauvegarde sur une plateforme de tests distincte de la plateforme initialement sauvegardée. La plateforme de test de restauration doit être en mesure de vérifier que les applications, traitements et processus qui utilisent les données restaurées démarrent et fonctionnent comme attendu, c'est-à-dire au moins aussi bien qu'en production (aux écarts de performances près si le matériel est différent).
La fréquence des tests de restauration doit être adaptée à la criticité des données, et des processus/traitements métier qui les utilisent, pour l'organisation. Plus une application est critique pour la vie d'une entreprise plus il faudra procéder souvent aux tests de restauration.
Et le stockage dans le Cloud ?
Chaque solution de stockage cloud a ses propres caractéristiques en matière de protection contre la perte de données. Il est donc capital de vérifier que ces caractéristiques sont adaptées aux impératifs de protection qui pèsent sur les données.
Redondance
Les fournisseurs de solutions cloud proposent tous, ou presque, un stockage redondant et les données seront donc protégées contre les défaillances du matériel. C'est bien le moins que l'on peut attendre d'une solution de stockage dans le cloud !
Sauvegardes
Comme la politique de sauvegarde des données dépend essentiellement des besoins et des contraintes du propriétaire des données, les fournisseurs de solutions cloud ne peuvent pas fournir de solutions de sauvegarde qui feraient tout le boulot. Bien sûr, certains mettent à disposition des outils et/ou des moyens de sauvegarde, c'est parfois un simple espace de stockage additionnel.
C'est sur ces outils/moyens mis à disposition qu'il faut ensuite bâtir la solution technique pour implémenter la politique de sauvegarde.
En effet, un hébergeur français bien connu a subi un sinistre sur un de ces sites de l'hexagone. Nombre de ses clients réalisaient bien des sauvegardes des données présentes sur ce site. Mais beaucoup d'entre eux stockaient leurs sauvegardes sur le même site. Lors du sinistre ils ont donc perdu les données originales et les sauvegardes !
Conclusions
Chaque entreprise ou organisation, doit mettre en œuvre une stratégie qui mixe à la fois la redondance du stockage et une politique globale de sauvegarde (déclinée unitairement pour chaque application métier ou pour chaque ensemble fonctionnel de données). La redondance, pour se prémunir des défaillances matérielles et de leur impact quant à la disponibilité immédiate des données. La politique globale de sauvegarde, pour se prémunir quant à la perte d'intégrité des données mais aussi quant à la perte de disponibilité des données.
Quand tous les disques redondants d'un site ont cramé pendant l'incendie du datacenter ou des locaux de l'organisation, il ne reste bien souvent que les backups pour relancer l'activité de production informatique depuis un autre site.
Le mix redondance/sauvegardes et la politique globale de sauvegarde doivent être pensés sous l'impulsion de la direction générale de l'entreprise ou de l'organisation. C'est une stratégie qui concerne en premier lieu les propriétaires des données, avant d'être une affaire d'informaticien·ne·s. Le rôle de l'IT est d'apporter l'éclairage technique nécessaire à la mise au point de cette stratégie ; de rappeler ce qui est faisable et à quel prix ; d'aider les directions générales et les équipes métier à faire les arbitrages, y compris en matière de budget. L'IT ne peut pas se substituer aux propriétaires des données pour faire ces choix.
La ou les politiques de sauvegarde et la politique de redondance du stockage des données sont des éléments constitutifs de la stratégie du système de management de la sécurité de l'information (SMSI) au sens des normes ISO-IEC 27000.
Remerciements
Je tiens à remercier Denis FOURNIER, ex-collègue et désormais ami, grand spécialiste des sauvegardes et de la restauration de données.
Pour sa précieuse relecture de cet article. Mais aussi et surtout pour le partage de son expertise sur le sujet, durant toutes ces années à ses côtés.
