« Un malheur n’arrive jamais seul » selon un vieil adage et OVHcloud l’a récemment appris à ses dépens. En l’espace de 10 jours, le géant de l’hébergement a connu deux incendies, qui plus est au même endroit : son datacenter de Strasbourg. Retour sur une catastrophe qui marque la fin du premier trimestre du monde numérique français, mais avec des répercussions au-delà des frontières vu la place de l’hébergeur français au niveau international. Quelles leçons en tirer ?
Synopsis de l’incident
La nuit du 9 au 10 mars dernier, plus précisément à 00 h 47, deux techniciens en service au datacenter OVHcloud de Strasbourg ont remarqué de la fumée s’échappant d’une salle. Conscients du risque encouru pour une intervention en intérieur, ces derniers se sont abstenus d’agir directement et ont laissé faire les pompiers. Grâce aux caméras thermiques, les pompiers ont détecté deux onduleurs en feu. Au final, c’est tout le datacenter SBG2 qui part en fumée, au sens propre.
Le réveil a été douloureux, non seulement pour Octave Klaba, le CEO d’OVHcloud, et ses équipes mais également pour leurs clients. Comme si cela ne suffisait pas, bis repetita dans la soirée du 19 mars. Vers 19h, l’un des conteneurs du datacenter SBG1 prit feu alors que la firme ne s’était pas encore remise de la première catastrophe sur le SBG2. Les 130 employés mobilisés pour remettre en marche les infrastructures impactées par le premier incendie ont dû arrêter momentanément leurs interventions par précaution.
Le lendemain du deuxième incendie, OVHcloud a annoncé le déplacement des serveurs du SBG1 vers les autres infrastructures du site strasbourgeois et les autres campus à Gravelines et à Roubaix. Le 26 mars dernier, SBG4 fut le premier datacenter réactivé et à ce jour, plus de 90% des serveurs sont opérationnels, notamment les infrastructures dédiées au Cloud public. Par contre, les instances du Cloud privé accusent un léger retard.
Les données de certains clients parties en fumée
Outre deux employés particulièrement gênés par les fumées, ce double incendie n’a fait aucune victime mais les dégâts matériels et les pertes de données sont considérables. Selon les estimations, environ 14.000 personnes (plus ou moins 2.000) auraient perdu toute ou partie de leurs données suite à ces incidents. L’origine du premier incendie serait la défaillance d’un onduleur ayant subi une intervention quelques heures plus tôt tandis que celui du second reste relativement flou. Le feu ayant débuté dans une pièce non-exploitée et non-alimentée.
Ces incidents font taches dans notre paysage numérique national voire continental, dans la mesure où OVHcloud est le fer de lance du mouvement cloud européen se posant en alternative aux GAFA. Cette série d’incendie ne sera pas sans conséquences sur l’image de la firme et sur la confiance des clients classés grands comptes.
Backup et réplication, salvateur pour les clients avisés
Pour les clients d’OVHcloud, le premier bon réflexe à avoir est la vérification des termes du contrat, notamment la partie SLA (Service Level Agreement) en espérant que ledit contrat engage l’hébergeur à prévoir un backup régulier ou un backup en temps réel. Ces options étant facultatives, de nombreux clients mal conseillés ou ayant souhaité faire quelques économies sur ces options de sécurité ont souffert de conséquentes pertes de données et d’accès à leurs services, pertes parfois totales et irréversibles.
Quoi qu’il en soit, on ne le dira jamais assez, le meilleur réflexe pour préserver ses données c’est d’effectuer des sauvegardes de ses données le plus régulièrement possible sur un serveur distinct du serveur d’hébergement et idéalement dans un datacenter distinct.
Protéger une application, c’est assurer sa résilience, c'est-à-dire finalement assurer sa disponibilité optimale, et donc éviter la perte de service. La réplication permet de répondre à cette problématique de faultless. La réplication est en fait le basculement des applicatifs touchés par une perte de service ou une indisponibilité d’un node, vers un autre serveur voire un autre site d’hébergement géographiquement éloigné du site principal de stockage.
On différencie d’ailleurs les réplications synchrones et asynchrones pour des cas d’usages différents. La réplication synchrone concerne plutôt des clusters de base de données avec des volumes importants et/ou critiques, quant la réplication asynchrone des volumes plus faibles ou une réplication d’annuaire.
Quelque soit le cas d’usage, prévoir et planifier tant la sauvegarde que la réplication de ses données est LE préambule à tout plan de reprise (PRA) ou de continuité d’activité (PCA) et ce ne peut certainement pas être une option à laisser de côté que l’on gère pour soi ou pour d’autres une infra cloud et les services et données associées.
