Incendie OVHcloud : les entreprises découvrent leur absence de sauvegardes

Aucun cloud n’offre par défaut un plan de reprise d’activité

Christophe Bertrand constate que certains clients d’OVHcloud communiquent sur leur intention de faire héberger leurs sites et leurs applications ailleurs. « Mais ils courront exactement le même risque ailleurs ! Tant que les entreprises ne souscriront pas explicitement à des offres de redondance, elles s’exposeront au même danger de voir leurs données partir en fumée avec le reste du datacenter. Ce n’est jamais parce que les données sont hébergées dans le cloud, que le cloud endossera subitement la responsabilité de faire des copies ailleurs alors qu’on ne lui a pas demandé d’en faire. »

Il note une interprétation biaisée des arguments de redondance que mettent en avant AWS ou Azure. Les concurrents américains d’OVHcloud seraient bien plus habitués à vendre de la redondance dans un pays où les entreprises ont souvent besoin d’avoir une présence sur la côte ouest et une autre sur la côte est. Pour autant, si la redondance des données y est plus fréquente, elle est autant une option que chez OVHcloud. Et, hélas, l’histoire montre que le géant AWS, numéro un mondial du secteur du cloud, n’est pas plus à l’abri d’une catastrophe naturelle : en 2018, c’est son datacenter de Tokyo qui disparaissait dans les flammes.

« Il y a un énorme travail à faire pour éduquer les entreprises françaises. À la charge des fournisseurs, désormais, de saisir cette opportunité », indique Christophe Bertrand, en rappelant que cela fait pourtant quarante ans que tous les fournisseurs expliquent l’importance des sauvegardes aux entreprises françaises.

Un plan de reprise d’activité est un processus qui consiste à s’assurer que l’on est en mesure de remettre les services en opération suite à une panne. Le principe consiste à évaluer les scénarios de tous les incidents possibles et à mettre en place une parade, le plus souvent avec l’aide d’un prestataire. La parade n’est détaillée dans aucun règlement, mais elle consiste généralement à déployer trois sauvegardes – une sur site pour redémarrer tout de suite l’activité en cas d’incident mineur, une ailleurs, au cas où le site connaîtrait une catastrophe, et une encore ailleurs sur des supports très différents, comme des bandes ou des disques durs enfermés dans un coffre.

Le plan de reprise d’activité comprend par ailleurs le scénario précis de la remise en opération : en informatique, il ne suffit pas d’avoir des sauvegardes, il faut aussi savoir dans quel ordre les restaurer (par exemple pour ne pas écraser la commande en cours d’un client avec un formulaire vierge).

Sauvegardes des serveurs privés : plutôt de bonnes nouvelles

Selon le bulletin d’information publié par OVHcloud, les infrastructures détruites susceptibles de contenir des sauvegardes comprennent, en cloud privé :

- les stockages NAS (offres NAS/HA) qui se trouvaient sur les baies de disques de la salle 62B dans le bâtiment SBG1,

- les stockages objet (offres Datastore) qui se trouvaient sur les baies de disques des salles 62C (bâtiment SBG1), 70D et 72A (bâtiment SBG2),

- le stockage des sauvegardes Veeam (offres Managed Veeam Backup) qui était hébergé en divers endroits des bâtiments SBG1 et SBG2.

Si les entreprises qui utilisaient ces services sur Strasbourg ont respecté les bonnes pratiques de la sauvegarde, alors ce qui a été perdu était, au mieux, la sauvegarde de serveurs qui fonctionnent toujours ailleurs ou, au pire, la sauvegarde locale d’un serveur local ; et, dans ce cas, il suffit de restaurer le serveur depuis l’une des deux autres sauvegardes situées ailleurs. Encore une fois, si les entreprises avaient bien pensé à faire deux autres sauvegardes ailleurs.

Pour celles qui avaient négligé les sauvegardes additionnelles, il y a tout de même une bonne nouvelle : il se trouve que les sauvegardes par service FTP des serveurs privés hébergés à Strasbourg étaient, elles, stockées par défaut sur le site de Roubaix. Les sauvegardes par FTP sont l’un des services de sauvegarde « clés en main » proposés par OVHcloud, l’autre étant la sauvegarde par logiciel Veeam. Ces sauvegardes par FTP vers Roubaix sont aussi celles qu’OVHcloud fait lui-même pour s’assurer qu’il pourra relancer les serveurs de ces offres privées en cas d’incident mineur. Le fait que ces sauvegardes-là aient été faites sur un autre site tient du miracle : la restauration de données en cas d’incidents mineurs – les plus fréquents – est plus rapide quand les sauvegardes sont situées sur le même site que l’incident.

Les serveurs privés détruits, qu’il s’agisse de serveurs physiques « Bare Metal » ou de machines virtuelles hébergées sur des serveurs dédiés « host », sont ceux qui étaient dans les salles 61B, 61C et 62B du bâtiment SBG1, ainsi que tous ceux qui étaient dans le bâtiment SBG2. Tous sont récupérables grâce, à minima, à la sauvegarde FTP de maintenance qu’OVHcloud faisait sur son site de Roubaix.

Offres de cloud public : une mauvaise nomenclature entretient la confusion

Mais la majorité des petits clients d’OVHcloud a plutôt souscrit à une offre de cloud public. Dans cette catégorie, l’inventaire de l’hébergeur est pour le moins nébuleux. D’une part, les différentes machines virtuelles qui exécutent les sites web et les applications en ligne des entreprises fonctionnent physiquement depuis plusieurs clusters OpenStack (la technologie qui permet de les virtualiser). Or, jusqu’à cette semaine, OVHcloud avait eu la mauvaise idée de nommer ces clusters avec la même nomenclature que ses bâtiments, plongeant ses clients dans l’incompréhension la plus totale quant aux ressources détruites et celles seulement désactivées temporairement.

Désormais, OVHcloud a renommé ces clusters « os-sbg » ; ils apparaissent éventuellement sous la dénomination « VPS-sbg » lorsqu’on interroge les caractéristiques d’un site web avec la commande whois. Et, d’une manière générale, c’est la douche froide : les clusters os-sbg1, os-sbg3 et os-sbg4 sont détruits, tout comme os-sbg2, car, contrairement à ce que suggère leur nom, ils se trouvaient dans le bâtiment SBG2 disparu dans les flammes.
Pire, dans ce cas-là, les sauvegardes techniques que faisait OVhcloud pour parer aux incidents mineurs se trouvaient dans le même bâtiment et ont donc été également détruites. Encore une fois, ces sauvegardes-là n’étaient qu’une facilité interne d’OVHcloud ; il ne s’agissait en aucun cas des sauvegardes que les entreprises se devaient d’avoir.

Seules les machines virtuelles des clusters os-sbg5 et os-sbg6, physiquement situés dans le bâtiment SBG3, ont été épargnées. Leur disponibilité, conditionnée par la décontamination du bâtiment SBG3 et la remise en route des infrastructures sous-jacentes, pourrait se faire attendre jusqu’au début du mois d’avril.

Sauvegardes payantes : une inconnue à cause de la technique d’Erasure Coding

Ces machines virtuelles, dénommées VPS (Virtual Public Server), ou ces ensembles de machines virtuelles, dénommés PCI (Public Cloud Instances) s’accompagnaient de différents moyens de sauvegardes : outre les sauvegardes techniques d’OVHcloud, on dénombre des services de snapshots payants (pour redémarrer l’activité rapidement), des sauvegardes payantes (une copie de secours des données idéalement traitées sur un autre site), ainsi que des espaces de stockage supplémentaires pouvant accueillir des sauvegardes faites par les entreprises elles-mêmes.

Il existe deux cas de figure pour les snapshots des salles os-sbg1 à os-sbg4, situées dans le bâtiment SBG2 détruit (offres « VPS Snapshot Cloud/CloudRam » et « VPS Snapshot SSD Range »). Soit, ils ont été souscrits avant le 23 avril 2020 et étaient stockés sur des baies de disques d’appoint juste à côté des serveurs virtuels : ils sont dans ce cas perdus. Soit, ils ont été souscrits après le 23 avril 2020 et sont stockés sur des baies de disques qui bénéficient de la technique d’Erasure Coding. Cette technique, qui revient à une sorte de RAID, mais à l’échelle d’un datacenter, réplique des bouts de données ailleurs, ici sur d’autres baies de disques situées dans le bâtiment SBG3.

Si les morceaux répliqués sur SBG3 équivalent à 80 % des données d’un serveur, alors ce serveur est restaurable dans son intégralité. Le pourcentage des données répliquées ailleurs est fonction de règles mathématiques qui évoluent au fur et à mesure de l’activité. Dans tous les cas, rappelons que les snapshots, même payants, ne sont qu’un service d’appoint, absolument pas conçu pour restaurer des serveurs suite à un incendie. Parvenir à s’en servir pour restaurer des données dans ces conditions tient du miracle.

Le cas des sauvegardes est plus compliqué. Les sauvegardes payantes faites en FTP (offre « FTP Backup ») ont la même chance que celles des offres de cloud privé : elles sont stockées à Roubaix et permettent donc de restaurer les machines virtuelles.

En revanche, les sauvegardes faites sur site avec les offres « VPS Automated Backup » et « Backup Instance » étaient dans tous les cas stockées sur des baies de disques bénéficiant de l’Erasure Coding. Et c’est potentiellement un problème plus large que celui des snapshots. En effet, si les serveurs restaurables ne seront que ceux ayant 80 % de leurs contenus dispatchés sur SBG3, cela s’applique à tous les serveurs virtuels du bâtiment SBG2, mais aussi aux serveurs virtuels qui fonctionnaient depuis le bâtiment SBG3 (clusters os-sbg5 et os-sbg6) qui, lui, n’a pas brûlé. Encore une fois : le risque de ne pas pouvoir restaurer des serveurs virtuels sur SBG3 n’existe que si les entreprises n’avaient souscrit qu’à cette seule sauvegarde.

Une responsabilité qui reste à établir

Reste le cas des services de stockage en cloud public sur le site de Strasbourg, qui pouvaient servir eux aussi à stocker des sauvegardes. Les services de stockage en mode bloc (offre « Public Block Storage ») reposaient sur quatre clusters OpenStack : les trois premiers, os-ceph-sbg1, os-ceph-sbg2 et os-ceph-sbg3 étaient dans le bâtiment SBG2 et sont donc perdus. Le dernier, os-ceph-sbg5, a été épargné dans le bâtiment SBG3.

En revanche, les services de stockage « Public Cloud Archive » (PCA) et « Public Cloud Storage » (PCS) reposaient eux aussi sur des baies de disques en Erasure Coding. Dans le cas du premier, OVHcloud est catégorique : toutes les données sont perdues, car le bâtiment SBG3 ne contient que 68 % de leurs morceaux. Dans le cas du second, le bâtiment SBG3 contient 99,5 % des morceaux de la globalité du stockage, ce qui signifie que la plupart des fichiers sont restaurables, sauf ceux dont l’essentiel du contenu résidait dans les 0,5 % de morceaux brûlés avec SBG2.

« OVHcloud fait tout ce qu’il peut pour être transparent sur ces informations. Franchement, je leur tire mon chapeau, car cela est assez rare chez ses concurrents. Je vois que certains de ces concurrents l’accusent à présent de négligence, quant aux moyens qu’il avait mis en œuvre pour se prémunir d’un incendie. Ils ont tort de conclure trop vite. Ce genre d’événements sera traité de la même manière qu’un crash aérien : il faut attendre les résultats d’une enquête minutieuse qui établira, au regard des assurances, qui est le vrai responsable de l’accident. En l’occurrence, l’hébergeur, le fournisseur des équipements au départ du feu, ou la personne qui est intervenue sur ces équipements », conclut Christophe Bertrand.

ESG est la propriété du groupe TechTarget, également propriétaire du MagIT.