# Incendie chez OVHcloud à Strasbourg : ce que l’incident a changé chez nous > Des sites entiers rayés de la carte du jour au lendemain. Retour concret sur ce que l'incendie de Strasbourg nous a fait revoir, sans méthodologie générique. - Auteur : Clément Hadrot - Publié le : 2021-01-19 - Mis à jour le : 2021-01-19 - Catégorie : Hébergement & serveurs - URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/incendie-ovhcloud-strasbourg-retour-experience/ ## L’essentiel - Un tiers de nos sites était hébergé sur le site touché - La sauvegarde hors site a fait toute la différence - Certains clients n'avaient tout simplement pas de plan B Le message est tombé un mercredi tôt le matin, relayé en boucle dans les canaux d'exploitation avant même que la presse ne s'en empare : un incendie majeur touchait le centre de données d'OVHcloud à Strasbourg. Un des bâtiments du site, entièrement détruit par les flammes, un autre partiellement endommagé. Pour toute agence hébergeant des sites WordPress dans cette région, la question n'était plus théorique : combien de nos clients étaient concernés, et dans quel état allaient-ils se réveiller ? Cet article ne prétend pas dérouler une méthodologie générique de plan de reprise d'activité. Il raconte ce que cet incident précis nous a fait vivre, corriger, et changer dans nos pratiques, à chaud puis à froid, dans les semaines qui ont suivi. ## Le matin de l'incident : identifier qui est touché La première urgence n'était pas technique mais organisationnelle : savoir, site par site, lequel de nos clients était hébergé sur l'infrastructure impactée. Notre inventaire interne, tenu à jour de manière irrégulière jusque-là, s'est révélé insuffisant pour répondre vite. Certains contrats avaient changé de datacenter au fil des années sans que notre documentation ne soit systématiquement mise à jour. Ce défaut de traçabilité nous a coûté près de deux heures avant d'avoir une liste fiable des sites concernés, un délai inacceptable dans ce type de situation où chaque client potentiellement touché doit être contacté avant qu'il ne découvre lui-même la panne. Ce point a été le premier corrigé dans les semaines suivantes : un inventaire précis, avec datacenter et zone de disponibilité renseignés pour chaque client, revu à chaque changement de contrat. ## La sauvegarde hors site a fait toute la différence > L'essentiel à retenir : Un tiers de nos sites était hébergé sur le site touché ; La sauvegarde hors site a fait toute la différence ; Certains clients n'avaient tout simplement pas de plan B Sur les sites hébergés dans la zone touchée, la situation s'est scindée nettement en deux catégories. Ceux dont les sauvegardes étaient répliquées vers un stockage externe, chez un fournisseur différent et dans une région différente, ont pu être restaurés sur un nouveau serveur en quelques heures, avec une perte de données limitée à l'intervalle depuis la dernière sauvegarde réussie. Ceux dont la sauvegarde restait stockée sur le même site physique, ou pire, sur le même serveur que le site lui-même, n'avaient tout simplement plus rien à restaurer. Ce n'était pas une question de fréquence de sauvegarde mal réglée : la sauvegarde existait, elle avait juste brûlé avec le reste. - Nos sauvegardes répliquées vers un stockage objet chez un second prestataire, déjà en place avant l'incident pour une partie du parc, ont permis une restauration en moins de six heures pour les clients concernés. - Pour les rares sites où cette réplication externe n'était pas encore en place, faute d'avoir été généralisée à temps, la perte a été totale sur les données non répliquées ailleurs. - Aucune sauvegarde, même quotidienne, ne protège d'un sinistre physique si elle reste stockée dans le même bâtiment ou la même baie que le site qu'elle protège. ## Ce que les clients découvrent, souvent trop tard L'incident a aussi révélé un malentendu récurrent avec certains clients : beaucoup pensaient qu'héberger « chez un grand acteur du cloud » suffisait en soi à garantir une continuité de service en cas de sinistre majeur. Un fournisseur d'hébergement solide protège contre l'essentiel des pannes matérielles courantes, mais aucun datacenter, aussi robuste soit-il, n'est à l'abri d'un incendie, et la responsabilité de la sauvegarde applicative reste toujours du côté du client ou de son prestataire, jamais automatiquement de celui de l'hébergeur. Cette conversation, difficile à avoir après coup, aurait dû être posée avant : quel niveau de sauvegarde, avec quelle réplication géographique, pour quel budget. Nous avions cette conversation avec certains clients avant l'incident ; avec d'autres, elle n'avait jamais eu lieu, faute d'avoir été jugée prioritaire face à d'autres urgences de production. ## Ce qui a changé concrètement chez nous après coup Dans les mois qui ont suivi, trois décisions ont été prises et appliquées sans exception sur l'ensemble du parc que nous gérons : 1. Toute sauvegarde de production doit désormais être répliquée vers un stockage situé chez un fournisseur et dans une zone géographique différents de l'hébergement principal, sans exception, quel que soit le budget du client. 2. L'inventaire des clients par datacenter et zone de disponibilité est revu à chaque changement de contrat, et vérifié trimestriellement, indépendamment de tout incident. 3. Un exercice de restauration réelle, pas seulement une vérification que le fichier de sauvegarde existe, est désormais planifié périodiquement pour chaque client sous contrat de maintenance. > Cet incident n'a rien changé à notre confiance envers les grands hébergeurs cloud. Il a changé notre tolérance à l'idée qu'une sauvegarde qui n'a jamais quitté le même bâtiment que le site puisse être considérée comme une sauvegarde suffisante. ## En résumé L'incendie de Strasbourg n'a pas révélé une faille chez l'hébergeur concerné en particulier : il a révélé, chez nous comme chez beaucoup d'autres agences, un écart entre ce que nous pensions couvrir et ce que nous couvrions réellement. La leçon la plus utile qui en reste n'est pas de fuir tel ou tel fournisseur, mais de ne jamais confondre l'hébergement d'un site avec la sauvegarde qui le protège.