Team-Azerty

Comme vous avez pu le constater, le site de l'association est de nouveau en ligne. Ceux qui suivent notre actualité sur les réseaux sociaux (page Facebook, Twitter et Discord), ont pu suivre les raisons et les divers rebondissements connus ces derniers jours.

Ainsi, comme des milliers d'autres sites, nous avons été les victimes collatérales du terrible incendie du datacenter d'OVHCloud situé à Strasbourg. Notre VPS se situant dans le fameux SGB2 qui a entièrement brulé, cette dernière est donc irrécupérable !

Nous sommes situés au niveau de la fumée 😭

Plus précisément, voici un état des lieux de la situation, sans doute provisoire :

Item Etat Possibilité de récupération Action Porteur Temps estimé État
Serveur Détruit sans sauvegarde 0%
  • Rachat d'une nouvelle VPS
  • Configuration (installation de debian, des différents services, des comptes, des crons)
  • Modification des DNS
Olivier 4 à 5h Partiellement terminé :
  • Voir la rotation des cron
  • Les droits sur les répertoires
  • Mails.
  • Les sauvegardes automatiques
  • Les soucis de perfs.
  • Toutes les librairies php sont elles présentes ?
BDD Détruit mais avec sauvegarde quotidienne 100% Importer la sauvegarde quotidienne Aurélien 10 minutes Terminé
Application Détruit, sauvegarde du 14/01/2020 95%
  • Récupérer la sauvegarde du 14/01/2020
  • Mettre à jour phpBB et ses extensions
  • Réinstaller Matomo
Aurélien 2 à 3h Partiellement Terminé :
  • Manque Matomo
  • L'installation de  phpMyAdmin est à revoir.
  • Des bugs sont encore présent.
  • Des extensions du forum doivent être réinstallées.
Sauvegarde NA NA Définir une stratégie de sauvegarde qui aille au delà de la sauvegarde quotidienne de la Bdd. Olivier, Aurélien, Christophe NA Pas encore défini, mais promis juré on ne se laissera plus avoir.
MAJ Application Détruit, pas de sauvegarde NA Site mature, pas de grosses modifications entre le 14/01/2020 et le moment du crash. Seules quelques petites retouches, ainsi que des MAJ de librairies ont été faites. La principale difficulté est de savoir ce qui a été modifié (et de re-coder). Aurélien 10 à 20 Jours A venir
PJ du forum Détruit, sauvegarde du 14/01/2020 ~70%
  • Créer un script permettant de lister les fichiers perdus et le contexte (lien vers le message impacté)
  • Libre à chacun de re-up ces derniers
Tout le monde NA A venir
Edit : liste des PJ perdues
Photos des LAN Détruit, sauvegarde du 14/01/2020 100%
  • Relancer le script de miniaturisation
  • Faire les rotations d'image
  • Uploader sur le site
Aurélien 1 à 2h A venir
Photos des articles Détruit, sauvegarde du 14/01/2020 ~100% Uploarder les images sur le site Aurélien et JP 1à 2h A venir
Photos des actualités Détruit, sauvegarde du 14/01/2020 ~95% Retrouver via web.archive.org les images utilisées Aurélien 2 à 3 jours A venir
Covid-Invader Détruit, pas de sauvegarde ~80% Recoder le JS/PHP Aurélien 15 à 20 jours A venir

Comme vous pouvez le constater, la situation aurait pu être largement plus dramatique, libre à chacun d'apporter de l'importance à ce "patrimoine immatérielle" perdu et donc du devoir de mémoire qui s'impose (ou non justement).

Pour ma part, c'est très bête, mais j'aimerais pouvoir sauver ce que je peux, et chose encore plus bête, j'apporte une importance particulière à mon petit jeu à la con.

Quoi qu'il en soit, nous ne tenons pas OVHCloud pour responsable des données perdues. À moins de 5€ par mois, sans option de sauvegarde, nous ne pouvons nous ne prendre qu'à nous même de n'avoir pas mis en place de système sauvegarde automatique pour les fichiers comme nous l'avons fait pour la BDD, ou bien à minima faire plus régulièrement de sauvegardes manuelles.

Néanmoins, si l'on dépasse notre cas personnel, il ne faut pas dédouaner complètement OVH Cloud. Ainsi, certaines questions sont légitimes : comment un incendie a-t-il pu avoir un aussi gros impact sur le datacenter ? Quelle sécurité anti-feu était en place ? Quels éléments ont fait défaut ? Alors que comment un incident sur un datacenter a-t-il pu impacter autant de clients (SLA) ? Pourquoi certaines sauvegardes se trouvaient au même endroit physique que les serveurs ?

Notons également une communication laborieuse. Ainsi, le mercredi on nous communique la liste des datacenter concernés : 100% de SGB2, 33% de SGB1 détruit. La première chose que nous avons faite, c'est d'aller vérifier sur le panneau d'administration l'emplacement de notre VPS. Et, en l'espace de 48h, cette dernière "change de place" puisque contrairement à ce qui était indiqué, ce n'était pas en SGB1 mais en SGB2 que notre VPS se situait.

Le 10 mars nous sommes sur SGB1
Le 11 mars nous apprenons qu'en fait nous sommes sur le SGB2

Alors qu'OVHCloud envisageait de rentrer en bourse, alors qu'OVHCloud cherche à rivaliser avec les Google,  Microsoft et Amazon en termes d'hébergement et de cloud, tout ceci fait un peu tache.

Quoi qu'il en soit, cet épisode doit nous rappeler l'importance de la redondance des données jugées sensibles ou importantes. Que ce soit pour les serveurs, vos données personnelles, multiplier les sauvegardes sur différents supports / lieux est primordial.