Retour d'expérience · publié le
Incendie OVHcloud à Strasbourg : sauver un serveur sans sauvegarde en deux semaines
En mars 2021, l'incendie du datacenter d'OVHcloud à Strasbourg a coupé des milliers de serveurs. L'un d'eux faisait tourner une quarantaine de sites associatifs, sur un système de 2012, sans aucune sauvegarde ailleurs. Voici comment je l'ai déménagé chez un autre hébergeur, sans perte de données et sans coupure.
La nuit du 10 mars 2021
Le 10 mars 2021 à 0 h 47, un incendie se déclare dans SBG2, l'un des quatre bâtiments du datacenter d'OVHcloud à Strasbourg. Par précaution, l'électricité est coupée sur tout le site : les serveurs de SBG1, SBG2, SBG3 et SBG4 s'éteignent en même temps. Au matin, SBG2 est entièrement détruit et une partie de SBG1 aussi. L'hébergeur recommande à ses clients d'activer leur plan de reprise d'activité.
Quelques jours plus tard, une fédération associative nationale m'appelle. Son serveur se trouve sur le site. Il fait tourner une quarantaine de sites Drupal, gérés avec Aegir, et il n'en existe aucune sauvegarde ailleurs. Il n'y a donc pas de plan de reprise à activer.
Un sursis de deux semaines
Le serveur n'a pas brûlé. OVHcloud parvient à le remettre en route, mais pour deux semaines seulement : ensuite, la machine sera mise hors service. Tout ce qu'elle contient doit en être sorti avant.
Une quarantaine de sites en deux semaines, c'est serré. Mais le vrai problème n'était pas le volume.
Le vrai problème : Ubuntu 12.04
Le serveur tournait sous Ubuntu 12.04, une version sortie en 2012 et plus maintenue depuis 2017. Aucun hébergeur ne la propose plus à l'installation. Les sites dépendaient des versions précises des logiciels installés dessus : les passer sur un système récent voulait dire mettre à jour en même temps le système, Drupal, Aegir et tout ce qui les entoure, puis corriger ce qui casserait au passage.
Dans le délai imparti, c'était impossible. Il fallait d'abord mettre les sites à l'abri, à l'identique, et ne moderniser qu'ensuite.
Reconstruire la machine à l'identique
J'ai reconstruit le serveur chez moi, pièce par pièce, avant de toucher quoi que ce soit en ligne :
- une machine virtuelle VMware sur mon poste, avec une installation neuve d'Ubuntu 12.04 ;
- chaque service réinstallé dans sa version exacte, depuis les dépôts d'archives. C'est l'étape la plus délicate : ces paquets ne sont plus dans les dépôts habituels, et chaque dépendance doit correspondre ;
- les fichiers de configuration, les bases de données et les fichiers des sites copiés par SSH depuis le serveur en sursis ;
- tous les sites testés en local ;
- l'image finale envoyée chez DigitalOcean, choisi précisément parce qu'il accepte les images VMware personnalisées ;
- de nouveaux tests en ligne, avec un fichier /etc/hosts modifié sur mon poste pour voir les sites sur le nouveau serveur avant tout le monde ;
- enfin, la bascule des DNS.
Chacune de ces étapes pouvait bloquer toutes les suivantes : un paquet introuvable, une image qui refuse de démarrer, une base qui ne se recharge pas. C'est pour cela que tout a été validé en local d'abord.
Zéro minute de coupure
Tant que les DNS n'avaient pas changé, les visiteurs continuaient d'arriver sur l'ancien serveur, qui fonctionnait toujours. Quand ils ont basculé, le nouveau était prêt et déjà testé. Les sites sont repartis chez DigitalOcean en moins d'une semaine, sans aucune interruption.
Profiter de l'occasion
Une machine qu'on reconstruit entièrement, c'est le moment de regarder ce qu'elle expose. J'ai fait un audit de sécurité et corrigé les failles connues (CVE) encore ouvertes, qui auraient pu être exploitées.
Puis j'ai mis en place ce qui manquait depuis le début : des sauvegardes. Chaque jour, un serveur de sauvegarde vient chercher les données par SSH et les dépose sur un volume btrfs, où btrbk garde des instantanés en lecture seule : un par jour sur trente jours, un par semaine sur douze semaines, un par mois sur douze mois et un par an sur deux ans. Le serveur de production n'a aucun accès à ces copies. Une fois par semaine, l'ensemble est en plus archivé sur un stockage à froid, dans un troisième lieu.
Et depuis
Ce dispositif a tenu jusqu'à ce que la fédération remplace ses sites Drupal par une flotte de sites WordPress, toujours une quarantaine. Je les administre encore aujourd'hui, et aucun n'a été compromis depuis 2021.
Ce qu'une PME peut en retenir
- Une sauvegarde dans le même bâtiment ne protège pas d'un sinistre sur ce bâtiment. À Strasbourg, les données et les sauvegardes stockées dans SBG2 ont disparu ensemble. Au moins une copie doit se trouver ailleurs, hors d'atteinte du serveur qu'elle protège.
- Un système qui n'est plus maintenu transforme un incident en urgence. Sur une version récente, il aurait suffi de réinstaller chez un autre hébergeur. Ici, il a fallu reconstruire une machine de 2012 à l'identique.
- Une bascule se teste avant de se faire. Le fichier /etc/hosts permet de vérifier le nouveau serveur en conditions réelles, sans que personne d'autre ne s'en aperçoive.