Amis lecteurs bonsoir !
Étrange journée que cette journée du 10 mars 2021, car, s’il y a bien un risque qu’on envisage pas immédiatement pour son serveur, lorsqu’on fait la liste des périls qui le guettent, c’est celui de l’incendie. Eh oui, en ce mercredi 10 mars 2021, Unicoda, où plutôt son serveur de résidence, est parti en fumée avec le reste des serveurs et des sites hébergés dans le datacenter SBG2 d’OVH à Strasbourg.
Pour Unicoda, plus de peur que de mal, puisque si vous lisez ces lignes, c’est que nous sommes (déjà) de retour. C’est bien sûr un événement dont tout le monde se passerait. J’ai pu voir quelques annonces de données irrémédiablement perdues, par exemple, du côté des serveurs du jeu Rust. Un événement qui démontre encore une fois, l’importance des sauvegardes, et que, même en environnement contrôlé, personne n’est à l’abri.
Voici donc un petit retour pour décrire la façon dont nous avons réagi à cet incident.
Tout commence ce matin vers 10h, lorsque mon frère Mathieu m’appelle au téléphone, en me demandant où est hébergé Unicoda dans les infrastructures OVH. Il continue en m’annonçant qu’il vient de lire qu’un incendie s’est déclaré dans le datacenter SBG2, que tout SBG est à l’arrêt et que Unicoda ne répond plus. Je lui confirme qu’Unicoda est bien hébergé à Strasbourg dans SBG2 et vérifie rapidement la connexion au serveur (en échec bien sûr). Vérification dans mes mails, pas de rapport journalier de sauvegarde ce matin, le feu s’étant déclaré peu avant le processus de sauvegarde automatique.
Je prends ensuite un peu de temps pour réfléchir. Je suis à 80% sûr qu’Unicoda était hébergé dans SBG2, rien dans la console d’administration d’OVH ne permet de valider l’information, rien sur les factures. Le rapport de sauvegarde du 9 mars indique qu’il s’est terminé avec succès. Enfin, SBG est à l’arrêt pour plusieurs jours, voir semaine, il faut donc préparer le redéploiement d’Unicoda sur un nouveau serveur. Profitant d’une pause dans ma matinée de travail, je commande donc un nouveau VPS OVH dans le datacenter de Gravelines.
Arrive le temps de la pause méridienne. Le VPS n’étant toujours pas disponible, je commande un VPS chez Hetzner en Allemagne, VPS facturé à l’heure avec un plafond mensuel, extrêmement pratique pour effectuer des tests de courtes durées. Livraison en moins d’une minute. J’ouvre le dépôt contenant mon script de déploiement automatisé ansible, change les DNS pour pointer vers la nouvelle machine et démarre l’exécution. Quelques erreurs du fait d’une réorganisation récente de l’ensemble de mes rôles ansible (et dont les tests devaient avoir lieu dans les prochains mois) interrompront deux fois la réinstallation. Au troisième essai, après quelques dizaines de minutes, Unicoda est à nouveau accessible.
Quels enseignements retenir de cet incident ?
Comme énoncé déjà ici: sauvegarder, sauvegarder et sauvegarder !! Je suis une nouvelle fois très satisfait par la solution de sauvegarde et de déploiement automatique que j’ai mise en place pour Unicoda et qui est le résultat de plusieurs années d’améliorations. Néanmoins, il serait bon d’ajouter un deuxième emplacement distant de stockage des sauvegardes. En effet, si par un hasard extraordinaire, un problème similaire était arrivé au datacenter stockant la sauvegarde chiffrée, c’eût été retour à la sauvegarde enregistrée sur mon poste local et pouvant parfois remonter à plusieurs semaines. Un emplacement distant pour les sauvegardes, c’est bien, deux, c’est mieux.
Deuxième point à noter, en cas de réorganisation complexe des scripts de déploiement automatique, il aurait été utile de conserver une copie du dépôt avant réorganisation, lorsque les scripts fonctionnaient sans erreurs et avait été testé. Ainsi, on s’évite quelques corrections en état de stress et pressé par le temps. Cela est bien entendu variable en fonction du service affecté, dans le cas d’Unicoda, je ne suis pas à la minute près, bien que j’apprécie d’avoir le moins de temps d’indisponibilité possible.
Enfin, j’ai apporté des modifications sur le Time To Live (TLL) du champ A des DNS d’Unicoda, entrée DNS responsable de la redirection vers le serveur. J’avais jusqu’à présent laissé ce champ à la valeur par défaut dans l’interface à savoir 86400 secondes soit 1 jour. Si cela ne pose guère de problèmes dans le cas d’une migration programmée, où l’ancien serveur continue de fonctionner quelques jours, c’est plus embêtant dans le cas d’un incident comme celui d’aujourd’hui, où on voudra que la modification DNS soit propagée le plus rapidement possible une fois le serveur de remplacement opérationnel. J’ai donc choisi une valeur de 7200 secondes (2 heures) de TTL, ce qui me semble être un bon compromis.
En conclusion, Unicoda s’en sort bien, plus de peur que de mal. On a beau avoir un processus de sauvegarde, des scripts de déploiement automatique, un léger doute subsiste toujours. Cet incident a permis de vérifier, en dehors d’un événement programmé, que les processus mis en place fonctionnent: une très bonne chose. Il me reste à vérifier dans les prochains jours que la sauvegarde s’effectue correctement sur ce nouveau serveur et, dans les prochaines semaines, à migrer une nouvelle fois Unicoda pour un retour chez OVH. A tous mes camarades informaticiens ayant perdu un serveur dans cet incendie: courage !
P.S. Pour suivre l’avancement de la remise en service, voici les tickets liés à l’incident:
